《领域驱动设计模式、原理与实践》这本书总算是看完了，总结一下，明天看点别的。
1. 书上讲了什么内容
全书内容较多，一共有26章分为4个部分。
1.介绍DDD的概念和作用
在复杂的领域中构建应用程序会随着业务日益复杂，职责边界变得模糊、调用关系变的混乱，代码东拼西凑最终会导致项目继续快速发展，即使是进行后来进行重构也很可能会再次陷入同样的状况。主要是缺乏对领域的深入理解、没有构建通用语言、没有与领域专家进行交流捕获领域的关键信息，DDD主张在复杂的领域的核心域，开发人员、业务人员、领域专家要一起合作，构建通用语言词库，使用通用语言进行交流，将业务需求结合领域进行抽象构建领域模型，要保持业务模型、领域模型、代码模型的一致协调，在介绍领域层逻辑实现中，提到了领域模型的实现方式，它是一种面向对象的方式，专注与对象的行为而非状态，并和其他集中实现领域层的方式进行对比，DDD的设计是一种自上而下的，首先要关注的是领域对象，以前都是优先考虑数据表之间的关联关系，以前很多时候都没有区分业务对象、数据对象、领域对象。
对职责和边界方面，提出了有界上下文的概念，并列举了有界上下文的关联关系，这个可以在工作中找到类似的或者以后作为参考，领域模型要放在有界上下文内保持隔离。
此外这部分内容还介绍了DDD的实施成本、常见误区、适用场景，这部分还是挺重要的，方便做出取舍，比如简单业务场景、非核心域不必按照领域模型的方式实现领域层逻辑。
2.介绍有界上下文之间的通信
介绍有界上下文如何集成，比如是代码里面用命名空间、还是单独代码仓库，服务之间的通信一种是rpc直接调用，另一种就是异步消息驱动。
3.实现领域模型
通过引入实体、值对象、聚合、领域服务、工厂、存储库、领域事件、事件溯源这些概念，并介绍他们的职责和应用场景介绍了领域模型的实现，并介绍了领域模型是如何和问题域关联起来的。
4.应用程序设计模型
偏向于代码实现，之前强调了领域模型通过聚合根作为唯一入口，但是对于查询数据的时候发现实现复杂、性能低下，引入了CQRS（命令查询职责分离）设计方式，读取和写入分开，介绍了应用层和领域层的职责和关联关系，最后介绍了领域报告（BI报表）这部分需求的实现方式。
2. 工作中的运用
战略模式可以在工作中评估服务的职责划分是否合理，代码分层和职责上采用了如下结构。
DDD.png
-
domain
- entity：业务模型，出参、入参
- params：领域的入参
- result：领域出参
- entity+params+result = application.dto
- repo：相当于之前的dao的interface定义，实现在infra
- svc：领域层的方法和实现：单测
-
application
- assembler application.dto->domain.param
-
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 | - |
网友评论