[前文](前端怎么主导ddd架构落地(上) #文章# /post/716958…) 提到ddd架构现已需求前端来救场了,此情此景,现已不知道尴尬的应该是后端、技能司理仍是前端了,横竖程序员一定是很尴尬。标题便是为了吸引眼球的,纯前端假如不是特别闲,是无论怎么也不会干这事的(微前端ddd架构另说)。不论是谁,假如不去搞了解什么是ddd,哪怕是后端来了,给你三个月时间怕也搞不定。时间不多了,离季度查核方针(还好是跨季度。。)越来越近,假如我这个“技能司理”带着他们还不能搞定,那责任最大的便是我了,不论你会不会java!

咱仍是有策略的

在小公司,一般都是事务驱动的,我根本很少听说过哪个小公司创造了一个架构,搞出一个结构然后在业内进行了广泛推广。在IT职业利润越来越少的时代,那些宣扬自己是技能驱动的小公司都挺不自量力的,咱仍是老老实实地搞事务吧。不论是谁,从老板到底层程序员,每一个人都要了解,把事务搞了解比什么都重要,这是生存规律。就拿这个事来说,ddd这个东西,20年前就有了,在中国是近几年才火起来。你要真较真,国外的IT公司才真的叫技能驱动,互联网便是国外创造的,阿里腾讯都还在跟从学习然后在这根底上再创新,你小公司敢说自己是技能驱动?所以ddd的落地必定是要结合事务,由事务来推动和驱动落地,而不是专注学习ddd的每一个演化细节后再去动手,那样便是舍本求末了,人家早便是老练的东西,你拿来主义照做就行,把精力花在架构的细节是得不偿失的。这便是为什么,两后端搞一向没找对方向的原因,我不会java却能辅导他们进行ddd落地,由于我抓住了要害,这个要害点是事务,而非技能。只要抓住了事务这个要害点,技能的落地才干掷地有声。

现在的后端便是一套单体服务,中心的勾连我也没精力去剖析拆解,后端现已在上面试了3个月了,现已证明修改是无效的,那只要一条路–推翻重建!我的主意就很简单,就直奔主题,首要清晰需求,事务线的各个微服务需求独立,归于事务线又不仅仅只归于事务线,其他的事务线假如有需求也能够用到我们的微服务,这便是公司产品上云的意义。清晰需求后再拿着需求去找ddd能帮到我什么,你就会发现这需求跟ddd真的是很般配。这时候再去确认ddd要成什么样,我就有了一个很清晰的方针,我找材料直接就看标题切入而不是从头开端看。有了必要的常识储备后,我就有底气来重构了,而推倒现在的结构,前提是要重新进行规划,这个规划就得是按照ddd的规划思想来;规划好之后,再交由后端履行开发;当然,这个进程最好是有开发方案来护航,究竟无方案状况的成果现已失利地太显着了。

模型规划

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

根据以上关于ddd的了解,我首要想到的便是优先规划这个事务线的范畴模型。我其实便是画了一个思想导图,根据对此事务线的事务脉络整理,先简单画了一个体系的事务模块分类,然后,交给后台履行确认。由于后台在返回一个接口的时候,必定会有我不是很清楚的事务交叉细节。这样几个来回下来,我发现我大略画的范畴模型,甚至仍是过于细节了。成果,范畴模型进一步被精简了,直到各范畴之间看起来现已不再有任何的羁绊。整个进程能够用这张图来表明:

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

为了便于了解与履行,我让后端在每个范畴的后面加上相关的数据库表名,这样一来范畴层现已跟根底层的直接相关关系就现已锁定了。这一步十分重要,ddd架构的规划一定要十分细节,表本身的主外键关系一般便是微服务的鸿沟。由于我是先有项目,然后再做架构,所以我们是能够在有了范畴层后,从根底层往上推上去,假如一开端没有项目,我觉得需求从事务开端整理,从上往下规划到范畴层终究再进行表规划。不论是哪一种,其实最开端都应该优先完成范畴层的规划。

接下来,根底层就相对简单点了,所有的sql最多就相关2到3张表,大部分便是对一个表的增删改查。根底层还能够放一些其他的支撑组件及东西之类的,总之,全力支撑范畴层的各个微服务范畴功用完成。根底层不仅仅支撑范畴层,一起也会支撑着应用层、用户接口层。

然后是应用层,这又是一个十分重要的部分。由于范畴层现现已过事务层面被降维打平了,范畴层对外露出的,仅仅最根底的接口。比方这里面包含了一个用户范畴的微服务,假如我要查用户的权限信息,不好意思,现在只要用户根底信息的接口,还要经过用户找到他的人物,再经过人物找到权限,这只要三个独立的接口,你需求在组合这三个接口再对外露出出去,这便是应用层要做的作业。不过像这个例子比较有代表性,一般情况下,假如范畴足够典型,像用户权限这个接口,也是能够在范畴层内封装好,然后应用层就直接调用了。不然的话,应用层会变得十分的重,范畴层也由于过于简单而失去了应用到其他项目上的价值。

终究,为了不影响前端开发,本来的单体服务保持不变,从头新搭一个ddd架构服务;另外一点便是应用层终究需求与本来的单体服务相呼应,确保前端原先调用的接口不变,这样就不会增加前端的额定作业。

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

坚决地履行

范畴层、应用层和根底层这些规划好了之后,后端现已心里有数了,他们两个一开端不信任的眼神现已开端有光了,我觉得有必要抓住时机,再提升点技能司理的权威性。我环绕范畴层,以范畴中每张表为最小粒度,一天6张表,以这个规范来列方案,我用甘特图花了整整一天才排好。中心履行的进程就不再赘述了,究竟文章主要仍是讲技能落地的,故事现已足够完整了。

完美的成果

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

是谁的问题,现已不重要

事实证明,ddd架构的落地,一定是需求从事务层面临范畴层进行细粒度规划,才干确保规划出来的微服务足够低耦合高内聚。成果最重要,进程同样重要,做为一个菜鸟技能司理,是谁的问题现已不重要,重要是前端也能主导ddd架构落地!不是吗!?

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

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