前端如何主导ddd架构落地(下)

前文--前端如何主导ddd架构落地（上） 提到ddd架构已经需要前端来救场了，此情此景，已经不知道尴尬的应该是后端、技术经理还是前端了，反正程序员一定是很尴尬。标题就是为了吸引眼球的，纯前端如果不是特别闲，是无论如何也不会干这事的(微前端ddd架构另说)。不管是谁，如果不去搞明白什么是ddd，哪怕是后端来了，给你三个月时间怕也搞不定。时间不多了，离季度考核目标(还好是跨季度。。)越来越近，如果我这个“技术经理”带着他们还不能搞定，那责任最大的就是我了，不管你会不会java！

咱还是有策略的

在小公司，一般都是业务驱动的，我基本很少听说过哪个小公司发明了一个架构，搞出一个框架然后在业内进行了广泛推广。在IT行业利润越来越少的时代，那些鼓吹自己是技术驱动的小公司都挺不自量力的，咱还是老老实实地搞业务吧。不管是谁，从老板到基层程序员，每一个人都要明白，把业务搞明白比什么都重要，这是生存法则。就拿这个事来说，ddd这个东西，20年前就有了，在中国是近几年才火起来。你要真较真，国外的IT公司才真的叫技术驱动，互联网就是国外发明的，阿里腾讯都还在跟随学习然后在这基础上再创新，你小公司敢说自己是技术驱动？所以ddd的落地肯定是要结合业务，由业务来推动和驱动落地，而不是专心学习ddd的每一个演变细节后再去动手，那样就是本末倒置了，人家早就是成熟的东西，你拿来主义照做就行，把精力花在架构的细节是得不偿失的。这就是为什么，两后端搞一直没找对方向的原因，我不会java却能指导他们进行ddd落地，因为我抓住了关键，这个关键点是业务，而非技术。只有抓住了业务这个关键点，技术的落地才能掷地有声。

目前的后端就是一套单体服务，中间的勾连我也没精力去分析拆解，后端已经在上面试了3个月了，已经证明修改是无效的，那只有一条路--推翻重建！我的想法就很简单，就直奔主题，首先明确需求，业务线的各个微服务需要独立，属于业务线又不仅仅只属于业务线，其他的业务线如果有需要也可以用到我们的微服务，这就是公司产品上云的意义。明确需求后再拿着需求去找ddd能帮到我什么，你就会发现这需求跟ddd真的是很般配。这时候再去确认ddd要成什么样，我就有了一个很明确的目标，我找资料直接就看标题切入而不是从头开始看。有了必要的知识储备后，我就有底气来重构了，而推倒目前的框架，前提是要重新进行设计，这个设计就得是按照ddd的设计思想来；设计好之后，再交由后端执行开发；当然，这个过程最好是有开发计划来护航，毕竟无计划状态的结果已经失败地太明显了。

模型设计

ddd有一个代码模型，它有四层架构(基础层、领域层、应用层及用户接口层)，基础层通过sql语句查表数据，领域层调用基础层形成最基础服务。领域层会设计多个微服务，微服务之间不能相互调用，这里的微服务有一个概念叫聚合，你可以理解为一个小的领域。相比于ddd架构，普通的单体服务，一般是没有领域这块的说法，直接在应用层一个复杂sql搞定接口的全部逻辑，然后对外暴露一个接口出去就行了，基本普遍就是这个搞法。

基于以上对于ddd的理解，我首先想到的就是优先设计这个业务线的领域模型。我其实就是画了一个思维导图，基于对此业务线的业务脉络梳理，先简单画了一个系统的业务模块分类，然后，交给后台落实确认。因为后台在返回一个接口的时候，肯定会有我不是很清楚的业务交叉细节。这样几个来回下来，我发现我粗略画的领域模型，甚至还是过于细节了。结果，领域模型进一步被精简了，直到各领域之间看起来已经不再有任何的纠缠。整个过程可以用这张图来表示：

为了便于理解与执行，我让后端在每个领域的后面加上相关的数据库表名，这样一来领域层已经跟基础层的直接关联关系就已经锁定了。这一步非常重要，ddd架构的设计一定要非常细节，表本身的主外键关系一般就是微服务的边界。因为我是先有项目，然后再做架构，所以我们是可以在有了领域层后，从基础层往上推上去，如果一开始没有项目，我觉得需要从业务开始梳理，从上往下设计到领域层最后再进行表设计。不管是哪一种，其实最开始都应该优先完成领域层的设计。

接下来，基础层就相对简单点了，所有的sql最多就关联2到3张表，大部分就是对一个表的增删改查。基础层还可以放一些其他的支撑组件及工具之类的，总之，全力支撑领域层的各个微服务领域功能实现。基础层不仅仅支撑领域层，同时也会支撑着应用层、用户接口层。

然后是应用层，这又是一个非常重要的部分。由于领域层已经通过业务层面被降维打平了，领域层对外暴露的，只是最基础的接口。比如这里面包含了一个用户领域的微服务，如果我要查用户的权限信息，不好意思，现在只有用户基础信息的接口，还要通过用户找到他的角色，再通过角色找到权限，这只有三个独立的接口，你需要在组合这三个接口再对外暴露出去，这就是应用层要做的事情。不过像这个例子比较有代表性，一般情况下，如果领域足够典型，像用户权限这个接口，也是可以在领域层内封装好，然后应用层就直接调用了。不然的话，应用层会变得非常的重，领域层也因为过于简单而失去了应用到其他项目上的价值。

最后，为了不影响前端开发，原来的单体服务维持不变，从头新搭一个ddd架构服务；另外一点就是应用层最终需要与原来的单体服务相呼应，保证前端原先调用的接口不变，这样就不会增加前端的额外工作。

坚决地执行

领域层、应用层和基础层这些设计好了之后，后端已经心里有数了，他们两个一开始不信任的眼神已经开始有光了，我觉得有必要趁热打铁，再提升点技术经理的权威性。我围绕领域层，以领域中每张表为最小粒度，一天6张表，以这个标准来列计划，我用甘特图花了整整一天才排好。中间执行的过程就不再赘述了，毕竟文章主要还是讲技术落地的，故事已经足够完整了。

完美的结果

最终，我带着两个后端每天加班加点，花了近一个月时间，赶在最后时刻把后端的ddd重构完成了，最终的代码检查也顺利通过。

是谁的问题，已经不重要

事实证明，ddd架构的落地，一定是需要从业务层面对领域层进行细粒度设计，才能保证设计出来的微服务足够低耦合高内聚。结果最重要，过程同样重要，做为一个菜鸟技术经理，是谁的问题已经不重要，重要是前端也能主导ddd架构落地！不是吗！？

• 参考资料：极客时间《DDD实战课》

扫码关注 字节逆旅 公众号，为您提供更多技术干货！