DDD特点

• 使用充血领域对象，将数据和行为封装在一起，并与现实世界中的业务对象相映射，更加符合OO编程理念。
• 更容易抽象、分治业务，解决复杂问题。
• 相对的，如果逻辑简单，比如取数聚合，使用DDD的成本大于收益。

3种架构层次

• 架构设计分为：
  • 业务架构——根据业务需求设计业务模块及其关系
  • 系统架构——设计系统和子系统的模块
  • 技术架构——决定采用的技术及框架
• DDD：聚焦业务架构，制定可演进的到系统架构的映射方案。
• 微服务：
  • 设计可复用的和业务一致的系统架构。
  • 追求系统模块之间充分解耦，可以自由地选择合适的技术架构，去中心化地治理技术和数据。
  • 

战略模型

宏观上划分和集成限界上下文

领域

• 领域包含了问题域和解系统，可以映射为N个限界上下文。

限界上下文

• 划分：限界上下文应该从需求出发，按领域划分，遵循高内聚低耦合原则。
• 梳理关系：U上游，D下游。
  • 合作关系（Partnership）：两个上下文紧密合作的关系，一荣俱荣，一损俱损。
  • 共享内核（Shared Kernel）：两个上下文依赖部分共享的模型。
  • 客户方-供应方开发（Customer-Supplier Development）：上下文之间有组织的上下游依赖。
  • 遵奉者（Conformist）：下游上下文只能盲目依赖上游上下文。
  • 防腐层（Anticorruption Layer）：一个上下文通过一些适配和转换与另一个上下文交互。
  • 开放主机服务（Open Host Service）：定义一种协议来让其他上下文来对本上下文进行访问。
  • 发布语言（Published Language）：通常与OHS一起使用，用于定义开放主机的协议。
  • 大泥球（Big Ball of Mud）：混杂在一起的上下文关系，边界不清晰。
  • 另谋他路（SeparateWay）：两个完全没有任何联系的上下文。
• 不同限界上下文中的相同概念需要分别建模。
  • 如创作上线文中的图书、物流上下文中的图书侧重点不同。

架构

• 通常六边形架构，领域模型位于核心。
  

战术模型

具体使用建模工具来细化限界上下文

实体 Entity

• 当一个对象由其标识（而不是属性）区分时，这种对象称为实体。如：人。
• 包含数据和行为。
• 建议将属性的验证放到实体中。

值对象 Value Object

• 当一个对象用于对事务进行描述而没有唯一标识时，它被称作值对象。如：颜色信息。
• 具有不变性、相等性（可度量领域中的某个东西、可进行比较）和可替换性。
• 需要保证值对象创建后就不能被修改。

聚合 Aggregate

• 一组相关对象的集合，作为一个整体被外界访问，集合的根节点是聚合根。
• 设计聚合的原则：
  • 边界内的内容具有一致性：一个事务只修改一个聚合。如果难以实现考虑剥离聚合达到最终一致。
  • 设计小聚合：大部分的聚合都可以只包含根实体，而无需包含其他实体。即使一定要包含，可以考虑将其创建为值对象。
  • 通过唯一标识来引用其他聚合或实体。
  • 边界外使用最终一致性。

聚合根、实体、值对象

• 区别：
  • 从标识的角度：
    • 聚合根具有全局的唯一标识；
    • 实体只有在聚合内部有唯一的本地标识；
    • 值对象没有唯一标识，不存在这个值对象或那个值对象的说法；
  • 从是否只读的角度：
    • 聚合根除了唯一标识外，其他所有状态信息都理论上可变；
    • 实体是可变的；
    • 值对象是只读的；
  • 从生命周期的角度：
    • 聚合根有独立的生命周期；
    • 实体的生命周期从属于其所属的聚合，实体完全由其所属的聚合根负责管理维护；
    • 值对象无生命周期可言，因为只是一个值；
• 关联：
  • 聚合根到聚合根：通过ID关联；
  • 聚合根到其内部的实体，直接对象引用；
  • 聚合根到值对象，直接对象引用；
• 参考

领域服务

• 一些重要的跨实体的领域行为或操作，可以归类为领域服务。它既不是实体，也不是值对象的范畴。
  • 执行一个显著的业务过程，如下单。
  • 对领域对象转换。
  • 输入多个领域对象，输出计算结果。
• 微服务中，一切领域逻辑（如通过聚合根暴露的业务逻辑）均需要通过领域服务对外暴露。

领域事件

• 作用：消除两阶段提交，支持聚合内一致性原则，维护聚合间的一致性。

模块

• 一种控制限界上下文的手段，一般尽量用一个模块来表示一个领域的限界上下文。

适配层

• 防腐层：一个上下文通过适配器和另一个上下文交互。
• 资源库：对领域的存储和访问进行统一管理。

参考

• 领域驱动设计在互联网业务开发中的实践
• 实现领域驱动设计
• 避免写流水账代码