# 领域驱动设计

DDD 是一种架构设计方法，微服务是一种架构风格，两者从本质上都是为了追求高响应力，而从业务视角去分离应用系统建设复杂度的手段。两者都强调从业务出发，其核心要义是强调根据业务发展，合理划分领域边界，持续调整现有架构，优化现有代码，以保持架构和代码的生命力，也就是我们常说的演进式架构。

* DDD 主要关注：从业务领域视角划分领域边界，构建通用语言进行高效沟通，通过业务抽象，建立领域模型，维持业务和代码的逻辑一致性。
* 微服务主要关注：运行时的进程间通信、容错和故障隔离，实现去中心化数据管理和去中心化服务治理，关注微服务的独立开发、测试、构建和部署。

### 战略设计核心构件

| **域类型**   | **定义**        | **特征**                                    | **识别技巧**        | **案例**                                                                             |
| --------- | ------------- | ----------------------------------------- | --------------- | ---------------------------------------------------------------------------------- |
| **核心域**   | 业务核心竞争力所在     | <p>- 独特业务价值<br>- 高投入优先级<br>- 战略差异点</p>    | 是否直接解决核心业务问题？   | <p>电商的<strong>订单交易系统</strong><br>金融的<strong>风控引擎</strong></p>                      |
| **支撑域**   | 辅助核心域运作的定制化功能 | <p>- 支撑核心流程<br>- 需定制开发<br>- 非通用方案</p>     | 是否为专属业务需求且无法外包？ | <p>电商的<strong>促销规则引擎</strong><br>物流的<strong>路径优化系统</strong></p>                    |
| **通用域**   | 行业通用解决方案      | <p>- 现成方案可用<br>- 低业务差异性<br>- 避免重复造轮子</p>  | 是否有成熟产品/开源方案？   | <p><strong>用户认证模块</strong><br><strong>支付网关集成</strong><br><strong>日志监控</strong></p> |
| **子域**    | 大领域分解的独立问题域   | <p>- 逻辑功能单元<br>- 可对应限界上下文<br>- 高内聚低耦合</p> | 能否用一句话描述清晰职责？   | 电商的库存域、商品域、会员域...                                                                  |
| **限界上下文** | 子域的具体解决方案边界   | <p>- 明确系统边界<br>- 统一语义环境<br>- 独立模型/代码</p>  | 领域模型是否在此范围内无歧义？ | 订单上下文、物流上下文、支付上下文...                                                               |

#### 战术设计核心构件

| **概念**                   | **描述**                                              |
| ------------------------ | --------------------------------------------------- |
| **实体（Entity）**           | 具有唯一标识和生命周期的对象（如 `User`、`Order`）。                   |
| **值对象（Value Object）**    | 无唯一标识，通过属性描述特征（如 `Money`、`Address`）。                |
| **聚合（Aggregate）**        | 一组关联对象的集合，由**聚合根**统一管理（如 `Order` 聚合包含 `OrderItem`）。 |
| **聚合根（Aggregate Root）**  | 聚合的入口点，负责维护内部一致性和事务边界。                              |
| **领域服务（Domain Service）** | 处理跨聚合或无状态的核心业务逻辑（如 `TransferService`）。              |
| **领域事件（Domain Event）**   | 表示领域中发生的重要事件（如 `OrderCreated`），用于解耦系统。              |
| **资源库（Repository）**      | 管理聚合的持久化与检索（如 `IOrderRepository`）。                  |
| **工厂（Factory）**          | 封装复杂对象的创建逻辑（如 `OrderFactory`）。                      |

### 协作与模式

| **概念**                         | **描述**                                                                                                                                         |
| ------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------- |
| **统一语言（Ubiquitous Language）**  | 开发人员与领域专家共同创建的精确术语，确保沟通一致性。                                                                                                                    |
| **分层架构（Layered Architecture）** | <p>典型分层：<br>- <strong>用户界面层</strong>（UI）<br>- <strong>应用层</strong>（协调任务）<br>- <strong>领域层</strong>（业务逻辑）<br>- <strong>基础设施层</strong>（技术实现）</p> |
| **防腐层（Anti-Corruption Layer）** | 隔离外部系统或遗留代码，避免污染领域模型（如适配第三方支付接口）。                                                                                                              |
| **领域模型（Domain Model）**         | 对业务领域的抽象表示，包含实体、值对象、规则等。                                                                                                                       |

### 领域模型设计模式

| **概念**                      | **描述**                                   | **示例**                                                   |
| --------------------------- | ---------------------------------------- | -------------------------------------------------------- |
| **充血模型（Rich Model）**        | 将业务逻辑内聚到领域对象中（实体/值对象），而非服务层。             | `Order.cancel()` 方法封装状态校验、事件发布逻辑，而非在 `OrderService` 中实现。 |
| **贫血模型（Anemic Model）**      | **反模式**：领域对象仅有 getter/setter，业务逻辑集中在服务层。 | `Order` 类只有属性，业务逻辑全在 `OrderService` 中。                   |
| **领域能力（Domain Capability）** | 将领域内的特定能力抽象为独立对象（策略模式）。                  | `PricingStrategy` 接口实现不同定价策略（会员价、促销价）。                   |
| **规格模式（Specification）**     | 封装业务规则为可组合、可重用的逻辑单元。                     | `OrderIsCancelableSpec` 检查订单是否满足取消条件（状态 + 超时时间）。         |

### 从真实场景理解 DDD

以下用一个 **电商订单履约系统** 的真实场景串联 DDD 所有核心概念，通过用户故事展开：

#### 用户故事背景

> *作为消费者，我希望下单后系统自动扣减库存、计算优惠券、生成物流单，并在支付超时时自动取消订单，以确保购物体验流畅。*

#### 战略设计：划分业务边界

**识别子域与限界上下文**

| **子域类型**    | **限界上下文（Bounded Context）** | **职责**           | **用户故事关联**  |
| ----------- | -------------------------- | ---------------- | ----------- |
| **核心域**     | 订单上下文（Order Context）       | 处理订单创建、状态流转、支付超时 | 用户下单、支付超时取消 |
| **支撑子域**    | 库存上下文（Inventory Context）   | 管理商品库存扣减与回滚      | 下单后自动扣减库存   |
| **支撑子域**    | 促销上下文（Promotion Context）   | 计算优惠券和折扣规则       | 下单时自动计算优惠券  |
| **通用子域**    | 物流上下文（Shipping Context）    | 生成物流单号、对接快递公司    | 下单后生成物流单    |
| **上下文映射关系** |                            |                  |             |

{% @mermaid/diagram content="graph LR
A\[订单上下文] -- 调用扣减库存 --> B\[库存上下文]
A -- 获取优惠规则 --> C\[促销上下文]
A -- 推送发货事件 --> D\[物流上下文]" %}

#### 战术设计：领域模型实现

**订单上下文中的领域对象**

| **概念**     | **代码示例**             | **职责**            | **用户故事逻辑**      |
| ---------- | -------------------- | ----------------- | --------------- |
| **实体**     | `Order` (订单)         | 管理订单状态、支付倒计时      | 记录订单状态（待支付/已取消） |
| **值对象**    | `CouponInfo` (优惠券信息) | 封装优惠券金额、使用规则      | 计算订单最终价格        |
| **聚合根**    | `Order` (作为聚合根)      | 管理 `OrderItem` 列表 | 确保订单项总价与优惠计算一致  |
| **领域服务**   | `OrderCancelService` | 处理超时取消订单逻辑        | 30 分钟未支付自动取消订单  |
| **领域事件**   | `OrderCreatedEvent`  | 订单创建时触发           | 通知库存上下文扣减库存     |
|            | `OrderCanceledEvent` | 订单取消时触发           | 通知库存回滚、物流取消发货   |
| **资源库**    | `IOrderRepository`   | 持久化订单聚合           | 保存订单状态到数据库      |
| **关键代码逻辑** |                      |                   |                 |

```java
// 领域事件驱动库存扣减
public class Order {
  public void createOrder() {
    // ... 订单创建逻辑
    DomainEventPublisher.publish(new OrderCreatedEvent(this.items)); 
  }
}

// 库存上下文监听事件
public class InventoryHandler {
  public void onOrderCreated(OrderCreatedEvent event) {
    inventoryService.reduceStock(event.getItems()); // 扣减库存
  }
}
```

#### 协作与模式应用

**跨上下文协作**

| **协作模式**     | **实现方式**            | **用户故事场景**           |
| ------------ | ------------------- | -------------------- |
| **防腐层（ACL）** | 物流上下文封装第三方快递 API    | 生成物流单时转换数据格式，隔离外部变化  |
| **开放主机服务**   | 促销上下文暴露 RESTful API | 订单上下文通过 API 查询优惠券有效性 |
| **事件驱动**     | 通过消息队列传递领域事件        | 订单取消事件触发库存回滚         |

#### 关键 DDD 决策与业务价值

1. **聚合根守护一致性**\
   `Order` 聚合根控制订单状态变更，确保状态流转合法（如**已支付的订单不可取消**）。
2. **领域事件解耦系统**\
   订单取消后发布 `OrderCanceledEvent`，库存/物流上下文异步处理，避免分布式事务。
3. **统一语言消除歧义**\
   开发与业务对齐术语：
   * **“支付超时”** = 订单创建后 30 分钟内未支付
   * **“优惠券不可叠加”** = 值对象 `CouponRule` 中实现 `calculate()` 逻辑
4. **上下文映射明确依赖**\
   订单上下文通过**防腐层**调用物流服务，避免第三方 API 变更污染核心域。

#### 用户故事完整流程

1. 用户提交订单 → **订单上下文**创建 `Order` 聚合根
2. 发布 `OrderCreatedEvent` → **库存上下文**扣减库存
3. **促销上下文**返回优惠计算 → 订单生成最终价格
4. 用户 30 分钟内未支付 → **领域服务**`OrderCancelService` 触发取消
5. 发布 `OrderCanceledEvent` → 库存回滚 + 物流取消发货

> **DDD 核心价值**：通过限界上下文隔离业务复杂性，领域模型精确表达业务规则，事件驱动实现高内聚低耦合。