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

·  阅读 1472

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

咱还是有策略的

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

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

模型设计

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

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

未命名文件 (3).png

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

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

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

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

坚决地执行

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

完美的结果

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

是谁的问题,已经不重要

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

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

本文正在参加「金石计划 . 瓜分6万现金大奖」

收藏成功!
已添加到「」, 点击更改