common-domain-driven-design

通用领域驱动设计

运用领域驱动设计（DDD）对复杂业务领域进行建模，明确划分边界，并编写易于维护、能清晰表达意图的代码。

适用场景

在以下情况下使用此技能：

• 设计或重构领域模型
• 创建新的限界上下文、聚合、实体或值对象
• 实现领域事件、仓储或应用服务
• 检查代码是否将领域逻辑与基础设施正确分离
• 与利益相关者讨论或记录通用语言

核心概念

通用语言

• 领域专家与开发人员使用统一、共享的词汇。
• 领域层中的每个类、方法和变量都必须使用通用语言中的术语。
• 如果某个术语有歧义，应先明确其含义并记录达成一致的定义。

限界上下文

• 限界上下文是一个明确的边界，在其范围内定义并保持领域模型的一致性。
• 不同限界上下文可以对同一术语有不同含义，这是正常的。
• 限界上下文之间通过定义明确的接口（上下文映射）进行通信：防腐层、共享内核、开放主机服务或已发布语言。

构建模块

构建模块	用途
实体	具有唯一标识且会随时间持续存在的对象。
值对象	仅由其属性定义、没有标识的不可变对象。
聚合	由实体和值对象组成的集群，以单个根实体作为入口。
聚合根	外部代码唯一可用于引用该聚合的实体。
领域事件	记录领域中发生的重要事项。
仓储	抽象持久化操作；检索和存储聚合。
领域服务	不适合归属于实体或值对象的无状态操作。
应用服务	协调用例；委托给领域对象，不包含业务逻辑。
工厂	封装聚合或实体的复杂创建逻辑。

说明

1. 识别限界上下文。 编写代码前，确定你正在处理哪个限界上下文，并明确写出其名称。如果尚不存在限界上下文，请使用通用语言提出一个。

2. 定义通用语言。 列出与任务相关的关键领域术语，并在代码、注释、提交消息和文档中统一使用这些术语。

3. 谨慎建模聚合。

   • 每个聚合都应尽可能小，只包含强制执行不变量所需的内容。
   • 通过标识（ID）引用其他聚合，而不是直接引用对象。
   • 所有状态变更都必须通过聚合根进行。
   • 在聚合内部保护不变量，绝不允许外部代码使聚合进入无效状态。

4. 广泛使用值对象。

   • 对领域概念（例如 Money、EmailAddress、DateRange），优先使用值对象，而不是基本类型。
   • 值对象不可变：操作应返回新实例。
   • 通过比较所有属性来实现相等性。

5. 通过领域事件处理副作用。

   • 聚合完成有意义的状态变更时，应发出领域事件。
   • 使用通用语言并以过去时命名事件（例如，OrderPlaced、PaymentReceived）。
   • 事件应保持精简：仅包含使用方所需的数据。
   • 在事件处理器中处理副作用（通知、投影、集成），不要在聚合中处理。

6. 明确划分各层。

   • 领域层：实体、值对象、聚合、领域事件、仓储接口、领域服务。不得导入框架或基础设施。
   • 应用层：应用服务（用例协调器）、命令／查询处理器。仅依赖领域层。
   • 基础设施层：仓储实现、消息适配器、ORM 映射、外部 API 客户端。实现领域层／应用层定义的接口。
   • 表示／API 层：控制器、序列化器、DTO。负责在外部输入与应用命令／查询之间转换。

7. 仓储规则。

   • 每个聚合根对应一个仓储。
   • 仓储接口位于领域层；实现位于基础设施层。
   • 仓储仅返回和接收完整聚合（而非部分实体）。

8. 跨边界时应用上下文映射。

   • 使用防腐层（ACL）在你的模型与外部／遗留模型之间进行转换。
   • 在上下文边界定义明确的 DTO 或集成事件，绝不泄漏内部领域对象。
   • 如果两个团队共享一个小型模型，请使用共享内核，并明确所有权规则。

9. 文件夹／模块结构。 组织代码，使其与限界上下文相对应：

   src/
     <bounded-context>/
       domain/
         model/          # Aggregates, entities, value objects
         event/          # Domain events
         service/        # Domain services
         repository/     # Repository interfaces
       application/
         command/        # Command handlers / use cases
         query/          # Query handlers / read models
       infrastructure/
         persistence/    # Repository implementations
         messaging/      # Event bus adapters
       presentation/     # Controllers, DTOs
   

10. 验证设计。

    • 聚合根上的每个公共方法都应对应通用语言中的一个领域动作。
    • 如果无法使用领域术语为某个内容命名，请重新考虑模型。
    • 自问：“这个聚合能否在不依赖外部对象的情况下强制执行自身的不变量？”如果不能，请重新划分边界。
    • 确认业务逻辑没有泄漏到应用服务、控制器或基础设施中。