1. 领域驱动设计（DDD）基础：核心概念与战略设计

领域驱动设计（Domain-Driven Design，DDD）是一套应对复杂业务系统建模的方法论，由 Eric Evans 在其经典著作中提出。它强调以业务领域为核心，通过统一的语言（Ubiquitous Language）将业务概念精确映射到软件模型中。本章作为课程的开篇，将系统梳理 DDD 的核心概念与战略设计工具，为后续的模块边界划分与审批流故障排查奠定坚实的理论基础。

1.1 核心概念：战术建模的基石

战术建模（Tactical Modeling）提供了构建领域模型的具体模式。理解这些模式是进行有效领域建模的第一步。

1.2 聚合：事务一致性的边界

聚合是 DDD 中最重要的战术模式之一，它定义了数据一致性边界。在一个聚合内部，所有对象的修改必须在一次事务中完成并保证强一致性；跨聚合的修改则通过最终一致性实现。

// 聚合根示例：Order（订单）
public class Order {
    private OrderId id;          // 实体标识
    private List<OrderItem> items; // 内部实体列表
    private Money totalAmount;   // 值对象
    private OrderStatus status;  // 值对象

    // 外部只能通过聚合根的方法修改内部状态
    public void addItem(ProductId productId, int quantity, Money price) {
        // 业务规则校验：商品是否可售、数量是否超限
        this.items.add(new OrderItem(productId, quantity, price));
        this.totalAmount = this.calculateTotal(); // 重新计算总额
    }

    public void pay() {
        // 状态机校验：只有待支付状态才能支付
        if (this.status != OrderStatus.PENDING_PAYMENT) {
            throw new IllegalStateException("订单状态不允许支付");
        }
        this.status = OrderStatus.PAID;
        // 发布领域事件
        DomainEventPublisher.publish(new OrderPaidEvent(this.id));
    }
}

1.3 领域事件：解耦与异步通知

领域事件用于在聚合之间或限界上下文之间传递信息，实现松耦合。当一个聚合完成某个业务操作后，它会发布一个事件，其他感兴趣的订阅者可以异步响应。

• 发布者：通常是聚合根，在方法执行成功后发布事件。
• 订阅者：可以是同一个限界上下文内的其他聚合，也可以是不同限界上下文的服务。
• 典型场景：订单支付成功后，发布 OrderPaidEvent，库存服务订阅后扣减库存，通知服务订阅后发送短信。

1.4 战略设计：划定系统边界

当系统规模变大，单一模型无法覆盖所有业务时，就需要引入战略设计（Strategic Design）。战略设计的核心是限界上下文（Bounded Context）和上下文映射（Context Map）。

1.5 限界上下文：模型的边界

限界上下文是 DDD 战略设计的核心。它定义了一个显式的边界，在这个边界内部，领域模型、通用语言和代码实现保持高度一致。不同限界上下文之间通过明确的接口进行通信。

• 每个限界上下文拥有自己的通用语言：同一个术语在不同上下文中可能有不同含义。例如，“客户”在“销售上下文”中可能指购买者，在“售后上下文”中可能指报修人。
• 每个限界上下文拥有自己的模型和代码库：团队可以独立演进，技术栈也可以不同。
• 典型划分依据：业务能力（如订单、库存、支付）、子域类型（核心域、支撑域、通用域）。

1.6 上下文映射：协作模式

上下文映射描述了不同限界上下文之间的协作关系。常见的映射模式包括：

1.7 本章小结

本章介绍了 DDD 的两大支柱：战术建模（实体、值对象、聚合、领域事件）和战略设计（限界上下文、上下文映射）。这些概念是后续进行模块边界划分和审批流故障排查的基础。请务必理解：

• 聚合是保证数据一致性的最小单元，也是微服务拆分的候选边界。
• 限界上下文是微服务划分的逻辑依据，上下文映射决定了服务间的通信模式。
• 领域事件是实现服务间异步解耦的关键手段。