领域驱动设计（DDD）详解：从理论到实践的系统化指南

无名小组

已于 2025-05-20 13:58:34 修改

阅读量964

点赞数 16

分类专栏：架构 DDD 文章标签：领域驱动设计 DDD 限界上下文聚合根微服务架构领域模型软件架构设计

于 2025-05-16 13:53:52 首次发布

本文链接：https://blog.csdn.net/qq_38537286/article/details/148005319

版权

架构同时被 2 个专栏收录

7 篇文章

订阅专栏

DDD

1 篇文章

订阅专栏

摘要
领域驱动设计（Domain-Driven Design，DDD）是一种以业务为核心的设计方法论，旨在解决复杂业务场景下的软件架构难题。本文通过核心概念解析、实战案例拆解及分层架构设计，帮助开发者从零掌握DDD的核心思想与落地技巧。

一、DDD的本质：业务与技术的双向奔赴

1.1 为什么需要DDD？

传统开发模式中，技术实现与业务需求往往脱节，导致代码难以适应业务变化。DDD通过业务模型驱动技术架构，实现以下目标：

精准表达业务逻辑：将业务规则转化为代码模型（如“订单状态流转”直接映射为代码方法）。
降低系统复杂度：通过划分业务边界（限界上下文），避免模块间的混乱依赖。
提升团队协作效率：业务专家与开发人员使用同一套术语（泛在语言），减少沟通成本。

1.2 DDD的三大核心原则

统一语言（Ubiquitous Language）：业务术语直接作为代码命名（如Order.calculateTotalPrice()）。
限界上下文（Bounded Context）：明确模型的适用范围，隔离复杂性。
聚焦核心领域：区分核心业务（如电商的订单系统）与支撑业务（如支付网关），优先投入资源。

原则	说明	价值
统一语言（Ubiquitous Language）	业务术语直接作为代码命名（如 `Order.calculateTotalPrice()`）	减少沟通成本，确保一致性
限界上下文（Bounded Context）	明确模型的适用范围，隔离复杂性	模块清晰、职责明确
聚焦核心领域	区分核心业务（如电商订单）与支撑业务（如支付网关）	资源优先投入核心功能

二、DDD的核心概念与实践

2.1 基本元素解析

概念	定义	示例
实体（Entity）	具有唯一标识的对象，生命周期贯穿业务过程	`Order`（订单）、`User`（用户）
值对象（Value Object）	描述属性组合的不可变对象	`Address`（地址）、`Money`（金额）
聚合根（Aggregate Root）	聚合的入口点，负责协调内部对象状态	`Order`（订单）聚合根管理`OrderItem`（订单项）
领域服务（Domain Service）	封装跨实体/值对象的业务逻辑	`OrderPricingService`（订单计价服务）
仓储（Repository）	抽象数据访问，解耦领域模型与数据库	`OrderRepository`（订单仓储）

2.2 战略设计：业务全景图的构建

（1）限界上下文划分

步骤：
1. 与业务专家共同梳理业务流程（如“下单-支付-发货”）。
2. 根据业务规则差异划分上下文（如“订单上下文”、“库存上下文”）。
3. 确定上下文间的交互关系（如“订单上下文”依赖“库存上下文”的库存查询接口）。

案例：

// 订单上下文
public class Order {
  private OrderId id;
  private List<OrderItem> items;
  private Address shippingAddress;

  // 通过防腐层调用库存服务
  public void placeOrder(InventoryService inventoryService) {
    inventoryService.reserveItems(items);
    this.status = OrderStatus.PLACED;
  }
}

（2）上下文映射模式

客户-供应商模式：上游（供应商）提供API，下游（客户）封装适配层（防腐层）。
共享内核模式：共享核心模型（如Product实体），但需严格控制版本变更。

三、战术设计：从模型到代码的落地

3.1 分层架构设计

DDD推荐采用四层架构，职责分离清晰：

用户界面层（UI）：处理HTTP请求/响应（如Spring MVC Controller）。
应用层（Application）：协调领域层操作（如OrderService调用领域模型）。
领域层（Domain）：实现核心业务逻辑（如Order.calculateTotalPrice()）。
基础设施层（Infrastructure）：封装技术实现（如数据库访问、消息队列）。

// 应用层
public class OrderApplicationService {
  private final OrderRepository orderRepository;
  private final InventoryService inventoryService;

  public void createOrder(OrderCreateCommand command) {
    Order order = new Order(command.getItems(), command.getAddress());
    inventoryService.reserveItems(order.getItems());
    orderRepository.save(order);
  }
}

3.2 领域模型代码示例

// 聚合根
public class Order {
  private OrderId id;
  private List<OrderItem> items;
  private Address shippingAddress;
  private OrderStatus status;

  public void addItem(Product product, int quantity) {
    if (status != OrderStatus.DRAFT) {
      throw new IllegalStateException("只能在草稿状态添加商品");
    }
    items.add(new OrderItem(product, quantity));
  }

  public BigDecimal calculateTotalPrice() {
    return items.stream()
      .map(item -> item.getPrice().multiply(BigDecimal.valueOf(item.getQuantity())))
      .reduce(BigDecimal.ZERO, BigDecimal::add);
  }
}

// 值对象
@Value
public class Address {
  private String province;
  private String city;
  private String detail;

  public boolean isValidForDelivery() {
    // 验证地址合法性
    return !Strings.isNullOrEmpty(province) && !Strings.isNullOrEmpty(city);
  }
}

四、DDD在微服务架构中的实践

4.1 微服务与限界上下文的映射

每个限界上下文对应一个微服务：
- 订单上下文 → order-service（订单微服务）
- 库存上下文 → inventory-service（库存微服务）
服务间通信：
- 同步通信：通过REST API或gRPC调用。
- 异步通信：通过事件驱动（如Kafka发布OrderPlacedEvent）。

4.2 防腐层（ACL）的实现

当调用外部服务时，通过防腐层将外部接口转换为当前上下文的模型：

// 防腐层
public class InventoryAdapter implements InventoryService {
  private final RestTemplate restTemplate;

  @Override
  public void reserveItems(List<OrderItem> items) {
    // 将OrderItem转换为库存服务的ItemDTO
    List<ItemDTO> itemDTOs = items.stream()
      .map(item -> new ItemDTO(item.getProductId(), item.getQuantity()))
      .collect(Collectors.toList());

    restTemplate.postForEntity("http://inventory-service/reserve", itemDTOs, Void.class);
  }
}