- DDD特点
- 3种架构层次
- 战略模型
- 领域
- 限界上下文
- 架构
- 战术模型
- 实体 Entity
- 值对象 Value Object
- 聚合 Aggregate
- 聚合根、实体、值对象
- 领域服务
- 领域事件
- 模块
- 适配层
- 参考
- 使用充血领域对象，将数据和行为封装在一起，并与现实世界中的业务对象相映射，更加符合OO编程理念。
- 更容易抽象、分治业务，解决复杂问题。
- 相对的，如果逻辑简单，比如取数聚合，使用DDD的成本大于收益。
- 架构设计分为：
- 业务架构——根据业务需求设计业务模块及其关系
- 系统架构——设计系统和子系统的模块
- 技术架构——决定采用的技术及框架
- 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具体使用建模工具来细化限界上下文
- 当一个对象由其标识（而不是属性）区分时，这种对象称为实体。如：人。
- 包含数据和行为。
- 建议将属性的验证放到实体中。
- 当一个对象用于对事务进行描述而没有唯一标识时，它被称作值对象。如：颜色信息。
- 具有不变性、相等性（可度量领域中的某个东西、可进行比较）和可替换性。
- 需要保证值对象创建后就不能被修改。
- 一组相关对象的集合，作为一个整体被外界访问，集合的根节点是聚合根。
- 设计聚合的原则：
- 边界内的内容具有一致性：一个事务只修改一个聚合。如果难以实现考虑剥离聚合达到最终一致。
- 设计小聚合：大部分的聚合都可以只包含根实体，而无需包含其他实体。即使一定要包含，可以考虑将其创建为值对象。
- 通过唯一标识来引用其他聚合或实体。
- 边界外使用最终一致性。
- 区别：
- 从标识的角度：
- 聚合根具有全局的唯一标识；
- 实体只有在聚合内部有唯一的本地标识；
- 值对象没有唯一标识，不存在这个值对象或那个值对象的说法；
- 从是否只读的角度：
- 聚合根除了唯一标识外，其他所有状态信息都理论上可变；
- 实体是可变的；
- 值对象是只读的；
- 从生命周期的角度：
- 聚合根有独立的生命周期；
- 实体的生命周期从属于其所属的聚合，实体完全由其所属的聚合根负责管理维护；
- 值对象无生命周期可言，因为只是一个值；
- 从标识的角度：
- 关联：
- 聚合根到聚合根：通过ID关联；
- 聚合根到其内部的实体，直接对象引用；
- 聚合根到值对象，直接对象引用；
- 参考
- 一些重要的跨实体的领域行为或操作，可以归类为领域服务。它既不是实体，也不是值对象的范畴。
- 执行一个显著的业务过程，如下单。
- 对领域对象转换。
- 输入多个领域对象，输出计算结果。
- 微服务中，一切领域逻辑（如通过聚合根暴露的业务逻辑）均需要通过领域服务对外暴露。
- 作用：消除两阶段提交，支持聚合内一致性原则，维护聚合间的一致性。
- 一种控制限界上下文的手段，一般尽量用一个模块来表示一个领域的限界上下文。
- 防腐层：一个上下文通过适配器和另一个上下文交互。
- 资源库：对领域的存储和访问进行统一管理。
- 领域驱动设计在互联网业务开发中的实践
- 实现领域驱动设计
- 避免写流水账代码
