DDD 分层架构深度解析

🚀 5分钟理解 DDD

DDD（领域驱动设计）不是一个复杂的框架，而是一种思考方式。核心思想可以用三句话概括：

从一个简单例子开始

// Service 里充斥业务逻辑
public void withdraw(Long accountId, BigDecimal amount) {
  Account account = dao.findById(accountId);
  if (account.getBalance().compareTo(amount) < 0) {
    throw new Exception("余额不足");
  }
  account.setBalance(account.getBalance().subtract(amount));
  dao.update(account);
}

// 业务逻辑在实体内部
public class Account {
  public void withdraw(Money amount) {
    if (balance.lessThan(amount)) {
      throw new InsufficientBalanceException();
    }
    this.balance = balance.subtract(amount);
    addEvent(new WithdrawalMadeEvent());
  }
}

📋 学习路径

• 初级（1-2周）：理解聚合、实体、值对象的区别，能写充血模型
• 中级（1-2月）：掌握仓储模式、领域事件、防腐层，能设计限界上下文
• 高级（3-6月）：能进行事件风暴、上下文映射，处理复杂业务建模

战略设计：限界上下文 (Bounded Context)

在深入代码之前，必须理解 DDD 的战略设计。核心在于将复杂的业务领域划分为多个独立的限界上下文（Bounded Context）。 每个上下文都有明确的边界，内部拥有统一的通用语言（Ubiquitous Language）。

上下文映射（Context Map）则定义了不同上下文之间的集成关系（如防腐层 ACL、开放主机服务 OHS 等）。

🎯 DDD 适用场景诊断

并非所有项目都需要 DDD。以下清单帮助你判断：

典型适用场景

决策树

项目是否有复杂业务逻辑？
  ├─ 否 → 使用事务脚本或 CRUD 框架（如 Spring Data JPA）
  └─ 是 → 业务规则是否频繁变化？
      ├─ 否 → 可以使用传统三层架构
      └─ 是 → 团队是否有 DDD 经验？
          ├─ 否 → 先学习，小模块试点
          └─ 是 → 全面采用 DDD

1. 用户接口层 (User Interface)

职责：负责向用户展示信息和解释用户指令。它不包含业务逻辑，仅进行简单的数据校验和格式转换。

@RestController
@RequestMapping("/orders")
public class OrderController {
    
    private final OrderAppService orderAppService;

    // DTO (Data Transfer Object) 用于层间数据传输，避免暴露领域模型
    @PostMapping
    public Result<String> createOrder(@RequestBody CreateOrderRequest request) {
        // 调用应用层服务
        String orderId = orderAppService.createOrder(
            request.getCustomerId(), 
            request.getItems()
        );
        return Result.success(orderId);
    }
}

2. 应用层 (Application Layer)

职责：协调领域对象完成业务任务。它不包含业务规则，只负责编排流程（如事务控制、权限校验、发送事件）。

@Service
public class OrderAppService {
    
    private final OrderRepository orderRepository;
    private final ProductService productService; // 外部服务

    @Transactional
    public String createOrder(String customerId, List<OrderItemDTO> items) {
        // 1. 准备数据 (可能涉及其他上下文调用)
        Address address = customerService.getDefaultAddress(customerId);
        
        // 2. 调用领域层创建聚合根
        Order order = Order.create(customerId, address);
        
        // 3. 执行业务逻辑
        for (OrderItemDTO item : items) {
            order.addItem(item.getProductId(), item.getQuantity(), item.getPrice());
        }
        
        // 4. 持久化 (通过 Repository 接口)
        orderRepository.save(order);
        
        return order.getId().getValue();
    }
}

4. 基础设施层 (Infrastructure Layer)

职责：为其他层提供技术能力（数据库持久化、消息队列、Redis、第三方 API）。

关键点：通过实现领域层的接口，完成依赖倒置。

@Repository
public class OrderRepositoryImpl implements OrderRepository {
    
    private final JpaOrderDAO dao; // 具体 ORM 实现

    @Override
    public void save(Order order) {
        // 将领域模型转换为数据模型 (Data Model / PO)
        OrderPO po = OrderConverter.toPO(order);
        dao.save(po);
    }
}

📊 同一需求的两种实现

业务需求：用户下单，需检查库存、计算价格（含优惠券）、扣库存、创建订单、发送通知

🔄 逐步重构实战（账户转账）

假设我们接手一个遗留系统，需要将贫血模型重构为充血模型

❌ 贫血模型

• Entity 只有 getter/setter，无业务逻辑
• Service 层充斥业务规则
• 使用魔法字符串和 BigDecimal

✅ 重构步骤

• 第一步：创建值对象（Money、AccountStatus）封装基本逻辑
• 第二步：将业务规则迁移到 Account 实体（withdraw、deposit方法）
• 第三步：引入领域服务处理跨聚合操作（MoneyTransferDomainService）
• 第四步：简化应用层，只负责加载聚合和持久化
• 第五步：添加领域事件，实现解耦

领域事件 (Domain Events)

定义：领域事件是领域模型中发生的、业务专家关心的重要状态变更。它是实现最终一致性和系统解耦的关键机制。

// 领域事件定义
public class OrderCreatedEvent extends DomainEvent {
    private final OrderId orderId;
    private final String customerId;
    private final BigDecimal totalAmount;
    private final Instant occurredOn;
}

// 在聚合根中发布事件
public class Order extends AggregateRoot {
    public static Order create(String customerId, Address address) {
        Order order = new Order(customerId, address);
        order.addDomainEvent(new OrderCreatedEvent(order.id, customerId));
        return order;
    }
}

// 事件处理器
@EventHandler
public class OrderEventHandler {
    public void handle(OrderCreatedEvent event) {
        // 发送邮件、更新库存、记录日志等
        emailService.sendOrderConfirmation(event.getCustomerId());
    }
}

聚合的边界与一致性

核心原则：

• 事务边界：一个事务只能修改一个聚合实例
• 聚合之间通过 ID 引用：避免对象图过大,防止级联加载
• 最终一致性：聚合间的一致性通过领域事件异步实现

仓储模式深入

仓储 vs DAO：

防腐层 (Anti-Corruption Layer)

当与外部系统或遗留系统集成时,防腐层充当翻译器,保护领域模型不受外部模型污染。

// 防腐层实现
@Component
public class LegacySystemACL {
    private final LegacyApiClient legacyClient;

    // 将外部模型转换为领域模型
    public Product getProduct(String productId) {
        LegacyProductDTO dto = legacyClient.fetchProduct(productId);
        return Product.builder()
            .id(new ProductId(dto.getSkuCode()))
            .name(dto.getItemName())
            .price(new Money(dto.getPriceInCents() / 100))
            .build();
    }
}

1. 充血模型 vs 贫血模型

// ❌ Entity 只有数据,无行为
public class Order {
    private String id;
    private String status;
    // 只有 getter/setter...
}

// 业务逻辑全在 Service 层
public class OrderService {
    public void cancel(Order order) {
        if (order.getStatus().equals("SHIPPED")) {
            throw new Exception();
        }
        order.setStatus("CANCELLED");
    }
}

// ✅ Entity 包含业务逻辑
public class Order {
    private OrderId id;
    private OrderStatus status;

    // 业务行为封装在实体内部
    public void cancel() {
        if (status == OrderStatus.SHIPPED) {
            throw new DomainException("已发货订单不能取消");
        }
        this.status = OrderStatus.CANCELLED;
        addDomainEvent(new OrderCancelledEvent(this.id));
    }
}

2. 值对象的不可变性

值对象应该是不可变的,所有字段都是 final,通过构造函数或工厂方法创建。

public final class Money {
    private final BigDecimal amount;
    private final Currency currency;

    public Money(BigDecimal amount, Currency currency) {
        if (amount.compareTo(BigDecimal.ZERO) < 0) {
            throw new IllegalArgumentException("金额不能为负");
        }
        this.amount = amount;
        this.currency = currency;
    }

    // 不提供 setter,通过新对象返回操作结果
    public Money add(Money other) {
        if (!this.currency.equals(other.currency)) {
            throw new IllegalArgumentException("货币类型不匹配");
        }
        return new Money(this.amount.add(other.amount), this.currency);
    }

    // 重写 equals 和 hashCode,基于值相等
    @Override
    public boolean equals(Object o) { ... }
}

3. 领域服务的使用时机

何时使用领域服务：

• 操作涉及多个聚合,无法自然归属于某一个实体
• 业务规则需要访问外部资源(如调用外部定价引擎)
• 操作是无状态的业务算法

// 领域服务示例:转账操作涉及两个账户聚合
@Service
public class MoneyTransferDomainService {
    
    public void transfer(Account from, Account to, Money amount) {
        from.withdraw(amount);
        to.deposit(amount);
        // 发布领域事件
        eventPublisher.publish(new TransferCompletedEvent(from.id, to.id, amount));
    }
}

4. 工厂模式在 DDD 中的应用

当实体或聚合的创建逻辑复杂时,使用工厂模式封装创建细节。

public class OrderFactory {
    
    public Order createOrder(OrderCreationRequest request) {
        // 复杂的验证逻辑
        validateCustomer(request.getCustomerId());
        
        // 从多个来源组装数据
        Address address = addressService.getAddress(request.getAddressId());
        OrderId orderId = idGenerator.nextId();
        
        // 创建订单
        Order order = new Order(orderId, request.getCustomerId(), address);
        
        // 添加订单项
        request.getItems().forEach(item -> 
            order.addItem(item.getProductId(), item.getQuantity())
        );
        
        return order;
    }
}

🚀 DDD 架构中的性能考量

1. 聚合加载优化

• ❌ 错误：级联加载整个聚合，导致 N+1 问题
• ✅ 正确：聚合间只通过 ID 引用，按需加载

2. 查询与命令分离（CQRS 轻量版）

3. 仓储层缓存策略

• findById 先查 Redis 缓存，未命中再查数据库
• save 时更新缓存，设置合理的过期时间
• 使用 Redis 集群保证高可用

4. 领域事件异步化

• 使用 @Async 注解异步处理事件
• 或发送到消息队列（RabbitMQ、Kafka）
• 避免同步事件阻塞主流程

5. 性能监控指标

• 聚合大小：单个聚合的实体数量应 < 10 个
• 仓储查询：单次请求的仓储调用 < 5 次
• 事务时长：业务事务应在 100ms 内完成
• 领域事件：同步事件处理 < 50ms