2023 年，我主导了一个电商中台的 DDD 重构项目。从最初的「大泥球」单体架构到最终的领域驱动设计落地，我们踩了无数的坑。这篇文章不谈理论，只讲实战中用血泪换来的五条聚合根设计教训。

背景：那个让我们失眠的订单系统

老系统是一个典型的「上帝类」架构——OrderService 有 8000 多行代码，一个 createOrder 方法就包含了库存扣减、优惠券核销、积分计算、物流单创建等 12 个领域的逻辑。任何一个小改动都可能引发蝴蝶效应。

我们决定用 DDD 重构。但理论上的 DDD 和工程实践之间的鸿沟，远比教科书中描述的要深。

教训一：聚合根不是实体，是一致性边界

最初的设计中，我们把 Order（订单）设计成了一个巨大的聚合根，里面包含了订单项、收货地址、支付信息、物流跟踪、发票信息等所有关联实体。

// 错误示范：上帝聚合根
public class Order {
    private OrderId id;
    private List<OrderItem> items;          // 订单项
    private ShippingAddress address;        // 收货地址
    private PaymentInfo payment;            // 支付信息
    private List<LogisticsRecord> logistics;// 物流跟踪
    private InvoiceInfo invoice;            // 发票信息
    private CouponUsage couponUsage;        // 优惠券使用记录
    private List<OrderRemark> remarks;      // 订单备注
    
    // 一个方法改了 7 个实体的状态...
    public void confirmOrder() {
        // 验证库存、验证地址、创建支付单、生成物流单...
    }
}

问题很快暴露了：

微服务架构的流行带来了一个悖论：系统被拆分成更小的单元以降低复杂度，但服务之间的通信却创造了一个更复杂的分布式系统。如何治理这个「服务间的混沌」，是过去十年基础架构领域最重要的课题之一。

第一阶段：蛮荒时代（2014 之前）

在微服务概念刚刚兴起的时候，服务治理几乎等于「手写一切」：

服务 A 调用服务 B：

1. 自己实现服务发现（查 ZooKeeper / Nginx upstream）
2. 自己实现负载均衡（轮询 / 随机）
3. 自己实现重试（try-catch + 循环）
4. 自己实现超时（设置 HTTP timeout）
5. 自己实现熔断（状态机 + 计数器）

每一个服务的开发者都要重复实现这些逻辑，而且不同团队的实现质量参差不齐

这个阶段的核心问题是：治理逻辑和业务逻辑耦合在应用代码中。每一次修改治理策略（比如调整超时时间），都需要修改业务代码、重新编译、重新部署。

第二阶段：SDK 时代（2014-2017）

Netflix 开源了一整套微服务治理工具（Netflix OSS），标志着微服务治理进入 SDK 时代：

Netflix OSS 全家桶：

Eureka    → 服务注册与发现
Ribbon    → 客户端负载均衡
Hystrix   → 熔断器
Feign     → 声明式 HTTP 客户端
Zuul      → API 网关
Archaius  → 动态配置

Spring Cloud 在此基础上做了封装，让 Java 开发者可以用注解的方式快速接入：

@FeignClient(name = "user-service", fallback = UserServiceFallback.class)
public interface UserServiceClient {
    @GetMapping("/users/{id}")
    User getUser(@PathVariable("id") Long id);
}

@Component
public class UserServiceFallback implements UserServiceClient {
    @Override
    public User getUser(Long id) {
        return User.defaultUser();  // 熔断降级
    }
}

SDK 模式的问题

Netflix OSS 解决了「重复造轮子」的问题，但它引入了新的痛点：