[前文](前端怎么主导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架构的规划一定要十分细节，表本身的主外键关系一般便是微服务的鸿沟。由于我是先有项目，然后再做架构，所以我们是能够在有了范畴层后，从根底层往上推上去，假如一开端没有项目，我觉得需求从事务开端整理，从上往下规划到范畴层终究再进行表规划。不论是哪一种，其实最开端都应该优先完成范畴层的规划。
接下来，根底层就相对简单点了，所有的sql最多就相关2到3张表，大部分便是对一个表的增删改查。根底层还能够放一些其他的支撑组件及东西之类的，总之，全力支撑范畴层的各个微服务范畴功用完成。根底层不仅仅支撑范畴层，一起也会支撑着应用层、用户接口层。
然后是应用层，这又是一个十分重要的部分。由于范畴层现现已过事务层面被降维打平了，范畴层对外露出的，仅仅最根底的接口。比方这里面包含了一个用户范畴的微服务，假如我要查用户的权限信息，不好意思，现在只要用户根底信息的接口，还要经过用户找到他的人物，再经过人物找到权限，这只要三个独立的接口，你需求在组合这三个接口再对外露出出去，这便是应用层要做的作业。不过像这个例子比较有代表性，一般情况下，假如范畴足够典型，像用户权限这个接口，也是能够在范畴层内封装好，然后应用层就直接调用了。不然的话，应用层会变得十分的重，范畴层也由于过于简单而失去了应用到其他项目上的价值。
终究，为了不影响前端开发，本来的单体服务保持不变，从头新搭一个ddd架构服务；另外一点便是应用层终究需求与本来的单体服务相呼应，确保前端原先调用的接口不变，这样就不会增加前端的额定作业。
坚决地履行
范畴层、应用层和根底层这些规划好了之后，后端现已心里有数了，他们两个一开端不信任的眼神现已开端有光了，我觉得有必要抓住时机，再提升点技能司理的权威性。我环绕范畴层，以范畴中每张表为最小粒度，一天6张表，以这个规范来列方案，我用甘特图花了整整一天才排好。中心履行的进程就不再赘述了，究竟文章主要仍是讲技能落地的，故事现已足够完整了。
完美的成果
终究，我带着两个后端每天加班加点，花了近一个月时间，赶在终究时间把后端的ddd重构完成了，终究的代码查看也顺利经过。
是谁的问题，现已不重要
事实证明，ddd架构的落地，一定是需求从事务层面临范畴层进行细粒度规划，才干确保规划出来的微服务足够低耦合高内聚。成果最重要，进程同样重要，做为一个菜鸟技能司理，是谁的问题现已不重要，重要是前端也能主导ddd架构落地！不是吗！？
- 参考材料：极客时间《DDD实战课》
本文正在参加「金石方案 . 瓜分6万现金大奖」
