说说DDD领域驱动设计！

原创于 2025-08-05 14:46:05 发布 · 308 阅读

CC 4.0 BY-SA版权

文章标签：

领域驱动设计（DDD，Domain-Driven Design）是一种针对复杂业务系统的设计思想，核心是“让代码真正反映业务”。它解决了传统开发中“代码逻辑与业务脱节”“复杂业务难以维护”等问题，尤其适合电商、金融、医疗等业务规则复杂的系统。

一、为什么需要DDD？—— 从传统开发的痛点说起

假设我们开发一个电商系统的“订单模块”：

传统开发思路通常是“面向数据库设计”：先建表（订单表、订单项表），再写CRUD代码，最后把业务逻辑塞进Service层。
但实际业务可能很复杂：比如“订单提交”需要校验库存、计算优惠券、判断用户等级折扣、生成物流单……这些逻辑如果全堆在Service里，代码会变成“大泥球”，后续改一个小规则可能要动很多地方。

DDD的思路：先吃透“订单领域”的业务规则，用代码直接“翻译”业务，让代码结构和业务逻辑一一对应。比如“订单提交”这个业务动作，在代码中会有专门的领域对象和方法来承载，而不是零散分布。

二、DDD核心概念：专业解释+通俗类比+Java示例

1. 领域（Domain）

专业定义：指业务所涉及的范围和规则集合，比如“电商领域”包含订单、商品、支付、物流等子领域。
通俗类比：相当于“公司的业务部门”，比如电商公司的“订单部”“商品部”，每个部门有自己的业务范围和规则。
Java视角：领域是最高层的业务边界，代码中通常用包结构划分，比如com.xxx.ecommerce.order（订单领域）、com.xxx.ecommerce.product（商品领域）。

2. 限界上下文（Bounded Context）

专业定义：领域内的子边界，用于划分“业务语义一致”的范围，避免概念混乱。同一概念在不同上下文可能有不同含义（比如“商品”在“订单上下文”中是“已购买的商品”，在“库存上下文”中是“可售库存”）。
通俗类比：相当于“部门内的小组”，比如“订单部”分为“普通订单组”和“预售订单组”，两组对“订单状态”的定义可能不同（普通订单有“待发货”，预售订单有“待付尾款”）。
Java视角：用包进一步划分，比如com.xxx.ecommerce.order.normal（普通订单上下文）、com.xxx.ecommerce.order.preSale（预售订单上下文）。上下文之间通过“上下文映射”（Context Mapping）通信（比如接口调用）。

3. 聚合（Aggregate）与聚合根（Aggregate Root）

专业定义：
- 聚合：一组紧密关联的业务对象（实体/值对象）的集合，需保证这组对象的“数据一致性”。比如“订单”包含“订单项”“收货地址”，它们必须一起创建、一起修改，不能单独存在。
- 聚合根：聚合中唯一能被外部访问的对象，负责维护聚合内的一致性。比如“订单”是聚合根，外部只能通过订单操作订单项，不能直接修改订单项。
通俗类比：相当于“一个家庭”（聚合），“户主”（聚合根）是对外联系人，家里的成员（其他对象）只能通过户主沟通，保证家庭内部事务一致（比如买房必须户主出面）。

Java示例：

// 聚合根：订单
public class Order {
    private OrderId id; // 订单唯一标识（实体的核心）
    private List<OrderItem> items; // 订单项（聚合内的对象）
    private Address receiveAddress; // 收货地址（值对象）
    private OrderStatus status; // 订单状态

    // 只能通过聚合根操作内部对象，保证一致性
    public void addItem(Product product, int quantity) {
        // 校验：比如订单项数量不能为负
        if (quantity <= 0) {
            throw new IllegalArgumentException("数量不能为负");
        }
        items.add(new OrderItem(product.getId(), quantity, product.getPrice()));
    }

    // 提交订单（核心业务动作，聚合根负责协调内部状态）
    public void submit() {
        if (status != OrderStatus.DRAFT) {
            throw new IllegalStateException("只有草稿状态的订单能提交");
        }
        this.status = OrderStatus.SUBMITTED;
        // 触发领域事件（见下文）
        DomainEventPublisher.publish(new OrderSubmittedEvent(this.id));
    }
}

// 聚合内的实体：订单项（不能被外部直接访问）
class OrderItem {
    private ProductId productId;
    private int quantity;
    private BigDecimal price;
    // 构造器、getter等（无公开修改方法，保证只能通过聚合根修改）
}

4. 实体（Entity）

专业定义：有唯一标识（Identity），且其状态会随时间变化的业务对象。比如“订单”（有订单号）、“用户”（有用户ID），即使属性变化（比如订单状态从“草稿”变“已提交”），只要标识不变，就是同一个实体。
通俗类比：相当于“人”，每个人有唯一身份证号，即使换了衣服、发型（属性变化），还是同一个人。
Java特点：重写equals()和hashCode()时基于唯一标识（如订单号），而非属性。

5. 值对象（Value Object）

专业定义：无唯一标识，由属性值决定身份的对象。属性相同则视为同一个对象，属性变化则变成另一个对象。比如“地址”（省+市+街道相同则是同一个地址）、“金额”（100元人民币就是100元人民币）。
通俗类比：相当于“颜色”，“红色”就是红色，没有“唯一标识”，只要RGB值相同就是同一种红色。

Java示例：

// 值对象：地址
public class Address {
    private String province;
    private String city;
    private String street;

    // 构造器（全属性初始化，一旦创建不可修改，保证不可变性）
    public Address(String province, String city, String street) {
        this.province = province;
        this.city = city;
        this.street = street;
    }

    // 重写equals和hashCode，基于属性值
    @Override
    public boolean equals(Object o) {
        if (this == o) return true;
        if (o == null || getClass() != o.getClass()) return false;
        Address address = (Address) o;
        return Objects.equals(province, address.province) &&
                Objects.equals(city, address.city) &&
                Objects.equals(street, address.street);
    }

    @Override
    public int hashCode() {
        return Objects.hash(province, city, street);
    }

    // 无setter，保证不可变
}

6. 领域服务（Domain Service）

专业定义：当业务逻辑涉及多个实体/聚合，且不属于任何单个对象时，用领域服务封装。它是“动词”，负责协调多个对象完成跨聚合的业务操作。
通俗类比：相当于“跨部门协调员”，比如“订单支付”需要协调订单（改状态）、支付系统（扣钱）、库存（减库存），这个过程不属于订单或库存单独负责，就由“支付服务”来协调。

Java示例：

// 领域服务：处理订单支付（跨订单、库存、支付三个聚合）
@Service
public class OrderPaymentService {
    private final OrderRepository orderRepository;
    private final InventoryService inventoryService;
    private final PaymentGateway paymentGateway;

    // 构造器注入依赖
    public OrderPaymentService(OrderRepository orderRepository, 
                              InventoryService inventoryService, 
                              PaymentGateway paymentGateway) {
        this.orderRepository = orderRepository;
        this.inventoryService = inventoryService;
        this.paymentGateway = paymentGateway;
    }

    // 支付业务逻辑：协调多个聚合
    public void pay(OrderId orderId, PaymentInfo paymentInfo) {
        // 1. 获取订单
        Order order = orderRepository.findById(orderId)
                .orElseThrow(() -> new OrderNotFoundException(orderId));

        // 2. 校验订单状态
        if (order.getStatus() != OrderStatus.SUBMITTED) {
            throw new IllegalStateException("只有已提交的订单能支付");
        }

        // 3. 调用支付网关扣钱
        PaymentResult result = paymentGateway.pay(paymentInfo, order.getTotalAmount());
        if (!result.isSuccess()) {
            throw new PaymentFailedException(result.getReason());
        }

        // 4. 通知库存扣减
        inventoryService.reduceStock(order.getItems());

        // 5. 更新订单状态
        order.paySuccess(result.getTransactionId());
        orderRepository.save(order);
    }
}

7. 领域事件（Domain Event）

专业定义：领域中发生的重要业务事件（如“订单提交”“支付成功”），用于解耦跨上下文的业务流程。事件发布后，感兴趣的上下文可以订阅并处理。
通俗类比：相当于“公司公告”，比如“订单部”发布“订单已支付”公告，“物流部”订阅后开始安排发货，“财务部”订阅后开始记账，彼此不直接依赖。

Java示例（结合Spring事件机制）：

// 领域事件：订单已支付
public class OrderPaidEvent {
    private final OrderId orderId;
    private final LocalDateTime paidTime;
    private final String transactionId;

    public OrderPaidEvent(OrderId orderId, LocalDateTime paidTime, String transactionId) {
        this.orderId = orderId;
        this.paidTime = paidTime;
        this.transactionId = transactionId;
    }
    // getter
}

// 发布事件（在订单支付成功后）
public void paySuccess(String transactionId) {
    this.status = OrderStatus.PAID;
    this.paidTime = LocalDateTime.now();
    // 发布事件
    SpringApplication.getApplicationContext()
        .publishEvent(new OrderPaidEvent(this.id, paidTime, transactionId));
}

// 订阅事件（物流上下文处理）
@Component
public class LogisticsListener {
    @EventListener
    public void handleOrderPaid(OrderPaidEvent event) {
        // 创建物流单
        createDeliveryOrder(event.getOrderId());
    }
}

8. 仓储（Repository）

专业定义：封装领域对象的持久化操作，屏蔽数据库细节，让领域层专注于业务。比如OrderRepository提供findById()、save()等方法，底层可能用MyBatis或JPA实现，但领域层不关心。
通俗类比：相当于“档案管理员”，领域层只需要说“帮我找订单号123的档案”，管理员负责从档案室（数据库）找到并返回，领域层不用管档案存在哪个柜子（表）里。