前语
之前我写过一篇关于DDD文章，大白话之争辩DDD，阿里边试中台化理解，这次心血来潮是由于最近在看的一个关于范畴规划的课程，然后下面谈谈我读后感，以及在我实际项目里边终究用到哪些内容，最终还有今天看的美团的一篇 广告渠道化的探究与实践，能够发现路子挺野的，由于我还没到那个层次能驾驭他这种规划办法，后边也会讲到，感兴趣的同学赶忙搬个椅子听听～
课程相关感触
深化浅出 DDD便是这个课程，接下来我会大概讲下里边的内容，然后说下我的感触，最终谈谈我现在项目所做的范畴改造，以及还有哪些缺点需求改善。
课程内容
课程内容便是依照概念、然后分点举比方介绍，然后最终也有自己的demo，能够说合适小白入门的课程。可是归于入门级其他，理解我意思吗，深化一层在实际项目里边应用是如何的效果，终究我项目哪些当地要做这样的改造，仍是说全盘选用DDD理念，文章比较少钱讨论的。
我目前项目关于范畴改造
咱们项目从一开端就决定选用范畴方式规划办法，当然也是第一次接触，有些概念是不太明晰的，下面大致讲下。首要咱们选用经典四层的DDD架构，为什么呢？由于许多中心件根本是固定的，没有必要去依靠倒置，这种架构跟传统的mvc比较类似，接口层、应用层、范畴层、根底设施层。
应用层一开端不理解，所以很薄的一层，后边的话理解是服务编列的效果，会做范畴之间的编列。假如是那种直接一个范畴搞定的，就经过范畴服务处理即可。传统规划最杂乱最多代码的便是服务完成类，尽管这个项目是依照范畴来差异，可是没有去改动这个现状，所以导致完成类逻辑会杂。
顺下来，到dto跟中心转化，咱们也是直接beanutils去仿制参数，并没有选用防腐层那种去离隔，然后像数据库entity，ddd里边概念叫实体po，一般跟事务转化需求仓储层来转化，咱们也是直接拿entity用，下面我再详细说这样做的原因。
关于外部http恳求、rpc恳求，选用防腐层acl去离隔，当然这儿选用战略方式，不管是适配器方式仍是什么方式，这儿本质便是为了将体系跟外部离隔，便是体系需求什么东西，外部供给什么，而不是外部有什么我拿什么，削减强依靠。
类里边字段逻辑，仍是选用贫血模型，受之前开发思路的影响。
缺点
- 范畴层逻辑许多，比较杂。
解决方案：依照事务包再分包，比方说产品范畴，mybatis下面会有spu、sku、他们之间绑定关系，还有一些附加的东西，这些都是有自己servicImpl对吧，再加一个产品范畴模型，这个抽出来一个模块，这就很明晰，哪个模块对应什么servicImpl，不然或许需求看代码注释半响才知道这是之前做过什么需求。
- 没有仓储层转化
A: 这个不算缺点，咱们选用mybatis-plus自带封装service，自身自带来许多根本crud，为啥你非要自己重写呢？其次没有做po跟事务类转化，原因是不或许一步到位，或许这个事务需求这个参数，另一个事务需求另一个参数，所以便是都给，按需自己在范畴层处理
- 没有去完成值目标、实体、聚合根这些差异
A: 原因也很简单，目前阶段没有必要上到这个程度。有些扩展性要求很高的需求能够这么搞，比方咱们公司根底服务里边有个产品服务，里边会常常变化字段，这时分就需求上这玩意了。值目标是不变的东西，实体是包含整个目标生命周期的字段还有字段逻辑。关于变化很大的需求就好办了，不变了或许便是产品code，关于spu、sku信息是会改动的，能够放在实体里头，有些新加一些额定的字段，比方优化价格，咱们能够经过聚合类办法加上去，当咱们不需求的时分，不会影响这些不变的内容，这是优点。
DDD思维（进阶）
中心思维
高内聚、低耦合，这个便是范畴规划的中心思维。咱们从架构上，比方说六边形架构，外层都是适配器，低耦合；比方应用层服务编列，也是为了离隔服务之间依靠，仍是低耦合；防腐层是为了跟外部接口离隔，防止接口改动影响内部完成办法，也是低耦合；再到各层的转化，dto到事务bo，bo到po，层层转化，都是为了将他们离隔，字段不用全部输出，也是低耦合。
高内聚表现：选用充血模型，将字段的逻辑放在类里边，而不是在功用完成逻辑里头。这样的优点是什么呢？便是代码复用率，比方说a字段在逻辑b、c中都有，假如哪天需求变了，需求改动的当地一多就容易错，其次是提高代码复用率，也便是高内聚。
因需取材
我见过许多上来便是全套搬DDD的东西，有点为了技能而技能，作为研发人，我觉得应该理解为啥会有这种思维的呈现，什么时分咱们才需求去应用它，那我项目没有全盘选用是不是DDD呢？也算，便是咱们下面要讲的什么情况下需求做这层改造。
讲讲架构东西，从一开端是单体服务，当事务上来之后，机器扛不住，需求横向还有纵向去提升整个体系服务才干，事务逻辑也会开端杂乱起来，紊乱不堪，这时开端有soa面向服务的治理，将这些功用依照事务模块来差异，切割成独自的机器，这样能够提高独自模块的服务才干；再到后来有了ddd范畴规划思维，我觉得它是针对saas去做规划的，假如你依照paas去拆分了，其实没有所谓的再去界说范畴了，这时会呈现聚合层那些。关于saas里边会夹杂许多范畴，假如整在一块会跟炒面相同紊乱，ddd便是为了解决这个场景的。
什么时分要用到？
当体系事务现已杂乱到影响开发，或者说一开端做项目的时分这个事务便是比较杂乱，常常变化需求那种，就要这样规划。这让我想起之前面阿里的时分，面试官问我，mysql跟redis去差异是什么，什么时分要用redis？最终我去百度一下，mysql在200以上并发的时分功用越来越差，这时能够上redis。
同样的道理，咱们需求调查体系里边的东西是否现已达到需求拆分的等级，而不是强行为了技能而技能。
举个栗子：
1、关于外部http恳求，咱们有个报单的功用，需求对n多家供货商，假如你在一个办法里边写，那就翘翘了，一直叠加上去。这时选用规划模块战略方式，依据供货商编号进行不同报单恳求，这便是防腐层思路。
2、当范畴层许多service，这时新人接手的时分上手很慢，你需求跟它讲什么表，什么类，这时咱们再依据事务再分包，那就很清楚了。这个是不是高内聚表现，关于新人上手也是提效的，这才是有含义的。
3、关于各层转化，咱们项目是没有做一层特殊处理的，直接逻辑里边转，原因是没有必要去离隔。由于咱们许多逻辑都是直接仿制两个类的字段，没有做杂乱的逻辑处理，他们之间强耦合就强呗。可是关于一些公共办法，咱们确实是能够这么做，由于避免各个办法都去重写逻辑，增加bug危险。
4、假如全套依照ddd去规划，能够去统计下代码量有多少，直接翻上去，关于打包cicd是有影响的，对开发也没有所谓的提效。
这便是我为什么说那课程是初级，因需取材这方面没有打开太多。
美团的“野路子”
今天看到美团年度最佳文章展示，我看到里边一篇# 广告渠道化的探究与实践，然后仔细阅读之后，觉得路子太野了，由于我驾驭不了。
它这一篇文章跟ddd许多思维是一致的，所以咱们要用心的体会，而不是被浅层的皮毛所约束了思路。
咱们想起什么了嘛，值目标、实体的思维，便是把不变、扩展的拆开。
这个是什么思维呢？模块化思维，流程化思维，这是对事务熟悉根底概括出来的，也是工程师很重要的才干。模块化有多重要，比方说当你要改动东西的时分，我只需求加或者削减、或者变更模块即可，而不是像印度电线杆相同找半响都不知道需求改哪根电线。
路子很野的当地
首要这是什么？便是应用层的服务编列嘛，可是什么差异呢？它是在外部的，有点像聚合层，可是聚合层一般是一个服务去调其他服务整合数据，这个还能经过界面编列，老六了。我说个场景你就理解了，低代码渠道，这是跟我做过一个项目很类似的。
里边也是接口编列，然后对结果进行处理，然后返回。有个我吐槽最多的，便是数据处理上比传统会费事，比方说我写段逻辑，或许java我很快就写完了，关于低代码渠道我还要用js代码，golang代码处理，关于java开发同学是降效的，所以这块我不清楚美团是怎样去完成逻辑处理的，理论上也能够写java代码去整合不同模块数据。
这样做的含义
上面咱们也提到了不要为了技能而去应用技能，美团这么做为了让pm、测验、研发都能直观知道广告事务里边有哪些战略，分别完成什么功用，特别是新人下手的时分，所以这儿有个事务收集，关于现已完成的东西进行上报，qa同学也知道我需求测验的内容范围。
关于一般公司来规划： 便是新增一层聚合层，还无法完成调度引擎比较前沿的规划，当然关于一般公司现已够用了，所以说美团这样规划比较“野”，褒义词。
总结
期望咱们在学习完ddd根底知识根底上，在对事务一定熟悉程度上，因虚取材，这样才干真正发挥它的效果。然后咱们经过美团的技能方案，知道思维是更加重要的，而不是局限于方式上，它是我见过不相同的聚合层，或者说服务编列，当然也是我见过的仅仅没想到会以这样方式呈现（低代码渠道）。
