领域驱动设计总结篇

《领域驱动设计模式、原理与实践》这本书总算是看完了，总结一下，明天看点别的。

1. 书上讲了什么内容

全书内容较多，一共有26章分为4个部分。

1.介绍DDD的概念和作用

在复杂的领域中构建应用程序会随着业务日益复杂，职责边界变得模糊、调用关系变的混乱，代码东拼西凑最终会导致项目继续快速发展，即使是进行后来进行重构也很可能会再次陷入同样的状况。主要是缺乏对领域的深入理解、没有构建通用语言、没有与领域专家进行交流捕获领域的关键信息，DDD主张在复杂的领域的核心域，开发人员、业务人员、领域专家要一起合作，构建通用语言词库，使用通用语言进行交流，将业务需求结合领域进行抽象构建领域模型，要保持业务模型、领域模型、代码模型的一致协调，在介绍领域层逻辑实现中，提到了领域模型的实现方式，它是一种面向对象的方式，专注与对象的行为而非状态，并和其他集中实现领域层的方式进行对比，DDD的设计是一种自上而下的，首先要关注的是领域对象，以前都是优先考虑数据表之间的关联关系，以前很多时候都没有区分业务对象、数据对象、领域对象。

对职责和边界方面，提出了有界上下文的概念，并列举了有界上下文的关联关系，这个可以在工作中找到类似的或者以后作为参考，领域模型要放在有界上下文内保持隔离。

此外这部分内容还介绍了DDD的实施成本、常见误区、适用场景，这部分还是挺重要的，方便做出取舍，比如简单业务场景、非核心域不必按照领域模型的方式实现领域层逻辑。

2.介绍有界上下文之间的通信

介绍有界上下文如何集成，比如是代码里面用命名空间、还是单独代码仓库，服务之间的通信一种是rpc直接调用，另一种就是异步消息驱动。

3.实现领域模型

通过引入实体、值对象、聚合、领域服务、工厂、存储库、领域事件、事件溯源这些概念，并介绍他们的职责和应用场景介绍了领域模型的实现，并介绍了领域模型是如何和问题域关联起来的。

4.应用程序设计模型

偏向于代码实现，之前强调了领域模型通过聚合根作为唯一入口，但是对于查询数据的时候发现实现复杂、性能低下，引入了CQRS（命令查询职责分离）设计方式，读取和写入分开，介绍了应用层和领域层的职责和关联关系，最后介绍了领域报告（BI报表）这部分需求的实现方式。

2. 工作中的运用

战略模式可以在工作中评估服务的职责划分是否合理，代码分层和职责上采用了如下结构。

DDD.png

1. domain

   • entity：业务模型，出参、入参
   • params：领域的入参
   • result：领域出参
   • entity+params+result = application.dto
   • repo：相当于之前的dao的interface定义，实现在infra
   • svc：领域层的方法和实现：单测

2. application

   • assembler application.dto->domain.param

3. infra

   • assembler:entity和po的相互转换，repo使用
   • db：定义对每个数据表的操作，专项专用接口实现
   • po：数据对象
   • repo：实现domain的repo

层	入参类型	出参类型	assembler
net	pb定义的req	pb定义的resp	入参: pb.request转app.dto,调用app.svc。 出参：app.dto转pb.response,返回给请求方
application	dto	dto	入参：将app.dto 转domain.dto、domain.entity； 出参：将domain.dto、domain.entity转app.dto
domain	dto、entity	dto、entity	-
infra.repo	dto、entity	dto、entity	入参：domain.dto、domain.entity → db.po,也可能直接用domain.dto； 出参：db.po → domain.dto、domain.entity
infra.db	dto、po	po	-