欧创新《DDD实战课》一颗阅读整理
本文是阅读《DDD实战课》一刻的读后整理原文（原文可到极客时间自行购买）
一基础篇：
DDD 的核心知识体系：
2.DDD的设计思路：
3.用三步来划定领域模型和微服务的边界：
-
一步：在事件风暴中梳理业务过程中的用户操作、事件以及外部依赖关系等，根据这些要素梳理出领域实体等领域对象。
-
第二步：务紧密相关的实体进行组合形成聚合，同时确定聚合中的聚合根、值对象和实体。
-
第三步：根据业务及语义边界等因素，将一个或者多个聚合划定在一个限界上下文内，形成领域模型。在这个图根据领域实体之间的业务关联性，将业里，限界上下文之间的边界是第二层边界，这一层边界可能就是未来微服务的边界，不同限界上下文内的领域逻辑被隔离在不同的微服务实例中运行，物理上相互隔离
3.DDD 与微服务的关系：
4.核心域、支撑域和通用域
5.限定上下文：
-
通用语言确定了项目团队内部交流的统一语言，而这个语言所在的语义环境则是由限界上下文来限定的，以确保语义的唯一性。
-
而领域专家、架构师和开发人员的主要工作就是通过事件风暴来划分限界上下文。限界上下文确定了微服务的设计和拆分方向，是微服务设计和拆分的主要依据。如果不考虑技术异构、团队沟通等其它外部因素，一个限界上下文理论上就可以设计为一个微服务。
6.实体和值对象：
-
实体和值对象的目的都是抽象聚合若干属性以简化设计和沟通，有了这一层抽象，我们在使用人员实体时，不会产生歧义，在引用地址值对象时，不用列举其全部属性，在同一个限界上下文中，大幅降低误解、缩小偏差，两者的区别如下：
-
①两者都经过属性聚类形成，实体有唯一性，值对象没有。在本文案例的限界上下文中，人员有唯一性，一旦某个人员被系统纳入管理，它就被赋予了在事件、流程和操作中被唯一识别的能力，而值对象没有也不必具备唯一性。
-
②实体着重唯一性和延续性，不在意属性的变化，属性全变了，它还是原来那个它；值对象着重描述性，对属性的变化很敏感，属性变了，它就不是那个它了。
-
③战略上的思考框架稳定不变，战术上的模型设计却灵活多变，实体和值对象也有可能随着系统业务关注点的不同而更换位置。比如，如果换一个特殊的限界上下文，这个上下文更关注地址，而不那么关注与这个地址产生联系的人员，那么就应该把地址设计成实体，而把人员设计成值对象。
-
有些领域对象可以设计为值对象，也可以设计为实体，我们需要根据具体情况来分析。如果这个领域对象在其它聚合内维护生命周期，且在它依附的实体对象中只允许整体替换，我们就可以将它设计为值对象。如果这个对象是多条且需要基于它做查询统计，我建议将它设计为实体
7.如何设计一个聚合：
8.聚合的设计原则：
-
聚合内的实体对象数据一致性，边界之外的数据和聚合内的互不影响，也就是说一个聚合内的数据是一起的
-
设计小聚合，大聚合会导致实体太多，高频操作导致事务大，并发等问题
-
聚合之间的关联通过聚合根ID进行关联
-
通过应用层进行领域编排或者通过事件机制
9.领域事件：
二进阶篇：
1.传统MVC架构转基础的ddd架构（注意此处是最基础的ddd）
DDD 分层架构对三层架构的业务逻辑层进行了更清晰的划分，改善了三层架构核心业务逻
辑混乱，代码改动相互影响大的情况。DDD 分层架构将业务逻辑层的服务拆分到了应用层
和领域层。应用层快速响应前端的变化，领域层实现领域模型的能力。
另外一个重要的变化发生在数据访问层和基础层之间。三层架构数据访问采用 DAO 方式；
DDD 分层架构的数据库等基础资源访问，采用了仓储（Repository）设计模式，通过依赖
倒置实现各层对基础资源的解耦。
仓储又分为两部分：仓储接口和仓储实现。仓储接口放在领域层中，仓储实现放在基础层。
原来三层架构通用的第三方工具包、驱动、Common、Utility、Config 等通用的公共的资
源类统一放到了基础层
2.中台如何建模：
中台业务抽象的过程就是业务建模的过程，对应 DDD 的战略设计。系统抽象的过程就是微
服务的建设过程，对应 DDD 的战术设计。下面我们就结合 DDD 领域建模的方法，讲一下
中台业务建模的过程。
第一步：按照业务流程（通常适用于核心域）或者功能属性、集合（通常适用于通用域或支
撑域），将业务域细分为多个中台，再根据功能属性或重要性归类到核心中台或通用中台。
核心中台设计时要考虑核心竞争力，通用中台要站在企业高度考虑共享和复用能力。
第二步：选取中台，根据用例、业务场景或用户旅程完成事件风暴，找出实体、聚合和限界
上下文。依次进行领域分解，建立领域模型。
由于不同中*立建模，某些领域对象或功能可能会重复出现在其它领域模型中，也有可能
本该是同一个聚合的领域对象或功能，却分散在其它的中台里，这样会导致领域模型不完整
或者业务不内聚。这里先不要着急，这一步我们只需要初步确定主领域模型就可以了，在第
三步中我们还会提炼并重组这些领域对象。
第三步：以主领域模型为基础，扫描其它中台领域模型，检查并确定是否存在重复或者需要
重组的领域对象、功能，提炼并重构主领域模型，完成最终的领域模型设计。
第四步：选择其它主领域模型重复第三步，直到所有主领域模型完成比对和重构。
第五步：基于领域模型完成微服务设计，完成系统落地。
3.微服务代码结构（一种）
4.应用层需要跨领域调用怎么办
各层之间通过接口调用
第一种是应用服务调用并组装领域服务。此时领域服务会组装实体和实体方法，实现核
心领域逻辑。领域服务通过仓储服务获取持久化数据对象，完成实体数据初始化。
第二种是应用服务直接调用仓储服务。这种方式主要针对像缓存、文件等类型的基础层数据访问。这类数据主要是查询操作，没有太多的领域逻辑，不经过领域层，不涉及数据库持久化对象