DDD 使用总结

概念

领域：边界内要解决的业务问题域
子领域：在领域范围内对应一个更小的问题域或更小的业务范围

拆分过程

确认研究对象，即研究领域。
将对象进行细分，拆分为子领域。
每个子领域再拆分，行成更小子领域。

核心域

决定产品和公司核心竞争力的子域是核心域，它是业务成功的主要因素和公司的核心竞争力。
注册、登陆、充值、体现、下单、商品信息推送。

通用域

同时被多个子域使用的通用功能子域是通用域。
授权、认证等

支撑域：不属于通用功能，但是不包含决定产品和公司核心竞争力的功能。
订单拆分。

限界上下文

确定领域边界。

通用语言

在事件风暴过程中，通过团队交流达成共识的，能够简单、清晰、准确描述业务涵义和规则的语言就是通用语言。
通用语言包含属于和用例场景，并且能够直接反应在代码中。通用语言中的名词可以给领域对象命名、如商品、订单等，对应实体对象；而动词则表示是一个动作或实际，如商品已下单、订单已付款等，对领域事件或或者命令。

实体

1.标识符->历经状态变更后标识符不产生变化，拥有延续性和标识，甚至超出软件生命周期。
2.多个属性、操作或行为的载体。在事件风暴中，我们可以根据命令、操作或者事件，找出这些行为的业务实体对象，进而按照一定的业务规则将依存度高和业务关联紧密的多个实体对象和值对象进行聚类，行程聚合。
3.有ID标识，通过ID判断相等性，ID在聚合内唯一。状态可变，依附于聚合根，其生命周期由聚合根管理。实体一般会持久化，但是与数据库持久化对象不一定是一对一。

业务形态：实体和值对象是组成领域模型的基础单元。
代码形态：充血模型，跨多个实体的领域逻辑在领域服务中实现。
ps：充血模型：大多业务逻辑和持久化放在Domain Object里，Business Logic只是简单封装部分业余逻辑以及控制事务、权限等，层次Client ->(Business Facade)->BUsiness Logic -> Domain Object ->Data Access
优点面向对象，Business Logic符合单一职责，不像贫血模型包含所有的业务逻辑太过沉重。
缺点，如何划分业务逻辑，哪些逻辑在Domain Object，Domain Logic包含了持久化，对于开发者来说十分混乱，其次，Business Logic要控制事务，并且为上一层提供一个统一的服务调用入口点，必须把Domain Logic里实现的业务逻辑全部封装一遍。

贫血模型，只有get和set。所有业务逻辑都在Business Logic层。
优点，更层次单项依赖。
缺点，不够面向对象，领域对象知识作为保存状态和传递状态使用，只有数据没有行为。

聚合

领域模型内的实体和值对象就好比个体，而能让实体和值对象协同工作的组织就是聚合，它用来确保这些领域对象在实现共同的业务逻辑时，能保证数据的一致性。
1.高内聚、低耦合，它是领域模型中最底层的边界，可以作为拆分微服务的最小单位，但不建议对微服务过渡拆分。对性能有机制要求的场景，聚合可以独立未一个微服务。

聚合根

1.是一个实体。
2.聚合的管理者，负责协调实体和值对象按照固定的业务规则协同完成共通的业务逻辑。
3.具有全局唯一标识，有独立的生命周期。
4.一个聚合只有一个聚合根。

个人理解：
订单->聚合根
订单金额
订单商品列表
订单状态等实体聚合为一个聚合

聚合的一些设计原则

1.在一致性边界内建模真正的不变。
聚合用来封装真正的不变性，而不是简单地将对象组合在一起。聚合内有一套不变的业务规则，各实体和值对象按照统一的业务规则运行，实现对象数据的一致性，边界之外的任何东西都与该聚合无关，这就是聚合能实现业务高内聚的原因。

2.聚合设计的足够小。
如果聚合设计得过大，聚合会因为包含过多的实体，导致实体之间的管理过于复杂，高频操作时会出现并发冲突或者数据库锁，最终导致系统可用性变差。而小聚合设计则可以降低由于业务过大导致聚合重构的可能性，让领域模型更能适应业务的变化。

3.通过唯一标识引用其他聚合。
聚合之间的通过关联外部聚合根ID的方式引用，而不是直接对象引用方式。外部聚合的对象放在聚合边界内管理，容易导致聚合的边界不清晰，也会增加结合直接的耦合度。

4.在边界之外使用最终一致性。
聚合内数据强一致性吗，而聚合之间的数据保障最终一致性，实现聚合之间的解耦。

5.通过应用层实现跨聚合的服务调用。
避免跨聚合的领域服务调用和跨聚合的数据库表关联（同时意味着跨聚合事务也是不推荐的？）