DDD ，人都学习了，你还不赶紧抓紧学

Posted 2022-12-10 supingemail

好记忆不如烂笔头，能记下点东西，就记下点，有时间拿出来看看，也会发觉不一样的感受。

以下全是干货总结，实战代码不在此列，可关注微信公众号，留言获取相关资料。

目录

​一、DDD概念

二、方法论

三、技术架构

四、使用启发

五、总结

---

​一、DDD概念

1、是一种方法论，不是一种架构，是对软件所涉及到的领域进行建模，以应对系统规模过大时引起的软件复杂性的问题；

2、且对微服务系统的拆分以及项目的重构有章可循，避免依赖项目成员无章可循的经验进行拆分与设计；

3、是一种可以借鉴的思想，而非严格遵循的方法论。根据张逸老师和欧创新老师不同方式的领域建模可证实这一点。

二、方法论

一、张逸老师给出以下过程指导用于指导DDD方法论的落地，相比欧创新老师基于事件风暴的领域建模过程更易理解，事件风暴在识别领域对象过程有些含糊不易理解。

二、在实际项目中业务服务识别及撰写、统一语言需要业务人员更加紧密的合作，同时开发人员更易理解业务领域知识，为后续工作带来持久效益。

三、张逸老师给出可以落地的过程指导：

1、根据业务需求识别业务服务规约；

2、根据业务服务的服务名，按照知识语境与亲密度识别限界上下文；

3、识别业务活动描述中的名词、动词进行归纳抽象获得领域分析建模，得到领域对象；

4、根据UML类图的关系识别聚合；

5、根据业务服务的基本流程和验收标准分解任务到原子任务(可落地的映射关系：业务服务对应远程服务、应用服务编排业务流、领域服务组合服务、聚合承载原子服务操作)。

三、技术架构

1、不管是张逸老师的菱形架构还是欧创新老师的四层架构，都是基于分层架构进行设计。每一层只允许与直接位于其下方的层发生耦合。降低系统的复杂度，同时满足单一职责、高内聚、低耦合、提高可复用性；

2、在微服务的演进中，随着BC能力的填充以及对性能要求，将BC直接可以拆分成新的微服务系统；

3、菱形架构和四层架构也有自己的弊端，使得业务流经过更多的层级，相比传统MVC架构性能稍微有所消耗。

四、使用启发

1、首要解决通用语言问题，统一域语言。没有基于通用语言建立的所谓的聚合，实体，值对象，只是技术层面的一种设计方式；

2、领域模型会对查询带来一定的复杂性，可以通采用CQRS来分离Query和Command；当前项目关联字段较少通过冗余或者内存关联查询解决当前复杂性；

3、张逸老师的菱形架构相比欧创新老师的四层架构更加清晰，以及对仓储层的精简减少了DO到PO的互相转换，强调了富领域模型的优势。项目中要遵守各层的功能，不能写着写着又成了贫血模型的mvc架构。

4、可能DDD的技术实现上看起来很复杂，但实际这种开发方式是从业务的角度去分析问题，指引开发者去解决问题而存在的。

五、总结

1、不同实践者在多年实践中总结了自己的一套打法，降低了学习曲线。总的的可落地过程指导与分层架构略有差异，因此DDD没有最佳实践，不能只靠阅读就能充分理解，需要通过真正的实战并结合企业与项目团队实际情况，具体问题具体分析，不要硬套概念，提炼出适合自己的应用架构才是最好的；

2、DDD改变开发人员对业务领域的思考方式，要求开发者花费更多的时间和精力来思考业务领域、研究概念和术语。实现开发者对业务有了更准确的定义和理解，减少开发后期开发与业务的沟通成本。当然对于开发者的沟通能力要求有所要求。

3、技术活动往往需要综合运用多种知识，培训涉及到的周边支撑知识需要在业余时间进行查漏补缺；

更多精彩，请关注：码出精彩（codingba），我们一起学习探讨！