领域驱动设计

3 minAdvanced2026/6/14

DDD核心概念、限界上下文、聚合根、领域事件与战略/战术设计。

1. DDD核心概念

1.1 什么是DDD

领域驱动设计(Domain-Driven Design)是一套以业务领域为核心的软件设计方法论,强调技术与业务的深度融合。

1.2 核心原则

原则说明
统一语言团队使用相同的业务术语
模型驱动领域模型指导设计
持续学习深入理解业务领域
精炼提炼核心领域

2. 战略设计

2.1 限界上下文(Bounded Context)

限界上下文是语义边界,在其中领域模型有明确且统一的含义:

┌──────────────┐  ┌──────────────┐  ┌──────────────┐
│  订单上下文    │  │  商品上下文    │  │  支付上下文    │
│              │  │              │  │              │
│ Order        │  │ Product      │  │ Payment      │
│ OrderItem    │  │ Category     │  │ Transaction  │
│ OrderStatus  │  │ Inventory    │  │ Refund       │
└──────┬───────┘  └──────┬───────┘  └──────┬───────┘
       │                 │                 │
       └──── 上下文映射 ──┴─────────────────┘

2.2 上下文映射

关系说明
合作关系两个团队协商协调
客户-供应商下游需求驱动上游
遵奉者上游不考虑下游需求
防腐层(ACL)下游翻译上游模型
开放主机服务(OHS)上游提供标准协议
发布语言(PL)共享的事件/DTO格式

2.3 子域分

子域说明投入
核心域业务核心竞争力自研,最优
支撑域辅助核心业务自研或外包
通用域通用功能采购或开源

3. 战术设计

3.1 实体与值对象

概念特征示例
实体有唯一标识,可变用户、订单
值对象无标识,不可变地址、金额

3.2 聚合与聚合根

聚合是一致性边界,聚合根是聚合的唯一入口:

聚合: 订单
├── 聚合根: Order
│   ├── orderId (标识)
│   ├── customerId
│   └── status
├── 实体: OrderItem
│   ├── productId
│   ├── quantity
│   └── price
└── 值对象: Address
    ├── street
    ├── city
    └── zipCode

聚合设计原则

  • 聚合尽量小
  • 通过ID引用其他聚合
  • 一个事务只修改一个聚合
  • 跨聚合使用领域事件

3.3 领域服务

当业务逻辑不属于任何实体或值对象时,使用领域服务:

public class TransferService {
    public void transfer(Account from, Account to, Money amount) {
        from.debit(amount);
        to.credit(amount);
    }
}

3.4 领域事件

领域中发生的有意义的事情

public class OrderCreatedEvent {
    private final String orderId;
    private final String customerId;
    private final Money totalAmount;
    private final Instant occurredOn;
}

3.5 仓储(Repository)

提供聚合的持久化和检索接口

public interface OrderRepository {
    Order findById(OrderId id);
    void save(Order order);
    void delete(Order order);
}

4. 分层架构(DDD版)

┌──────────────────────────────┐
│        用户界面/展示层         │
├──────────────────────────────┤
│        应用层 (Application)   │  ← 用例编排
├──────────────────────────────┤
│        领域层 (Domain)        │  ← 核心业务逻辑
├──────────────────────────────┤
│        基础设施层 (Infra)      │  ← 技术实现
└──────────────────────────────┘
职责依赖方向
用户界面展示和交互→ 应用层
应用层用例编排、事务→ 领域层
领域层业务规则、领域模型无外部依赖
基础设施持久化、消息、外部服务→ 领域层(实现接口

5. DDD实践要点

要点说明
统一语言代码命名与业务术语一致
事件风暴团队协作发现领域事件
渐进式建模模型随理解深化而演进
防腐层隔离外部系统影响
持续重构随业务变化调整模型