领域驱动设计总结篇

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

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 -

你可能感兴趣的:(领域驱动设计总结篇)