DDD分层架构实战：从理论到落地的关键设计
1. DDD分层架构的核心设计理念
我第一次接触DDD分层架构是在一个电商系统重构项目中。当时系统已经发展到200万行代码，各种业务逻辑像意大利面条一样纠缠在一起，每次修改需求都像在走钢丝。这时候团队决定引入DDD分层架构，经过半年实践，系统终于变得清晰可控。那么，这个神奇的架构到底有什么魔力？
DDD分层架构的本质是业务复杂度治理工具。它通过纵向分层和横向限界上下文，将庞大的业务系统拆解为可管理的模块。最经典的版本包含四层：用户接口层、应用层、领域层和基础层。这就像建造一栋大楼，用户接口层是外立面装修，应用层是户型设计，领域层是承重结构，基础层则是水电管网。
与传统三层架构最大的区别在于领域层的独立。我曾见过不少项目把业务逻辑写在Service类里，结果这些类最后变成上帝类。而在DDD分层架构中，领域层是充血模型，每个领域对象都携带自己的行为。比如订单的折扣计算，应该放在Order实体里，而不是OrderService。
2. 领域层的实现细节
2.1 聚合根的设计陷阱
领域层的核心是聚合根设计，这也是最容易踩坑的地方。去年我们团队就发生过一个典型案例：商品聚合最初包含了库存信息，结果在高并发下单时出现严重的锁竞争。后来通过事件溯源模式将库存拆分为独立聚合，性能立即提升8倍。
好的聚合设计要遵循三个原则：
- 一致性边界：一个事务只修改一个聚合
- 小聚合：聚合不宜超过10个实体
- 通过ID引用：聚合间通过ID而非对象引用
实际项目中，我常用这个检查清单：
- 该聚合是否经常被整体加载？
- 修改时是否需要强一致性？
- 生命周期管理是否统一？
2.2 领域服务的正确用法
很多开发者容易把领域服务变成"杂物间"，把不好归类的方法都扔进去。其实领域服务应该满足三个条件：
- 执行的操作涉及多个实体
- 需要访问外部资源（如数据库）
- 操作本身是无状态的
比如电商中的"支付处理"服务，需要协调订单、支付单、账户等多个实体，还要调用第三方支付网关，这就是典型的领域服务场景。而像"计算订单金额"这种单一职责的操作，应该放在Order实体内部。
3. 应用层的编排艺术
3.1 服务组合模式
应用层最核心的价值是服务编排。在物流系统中，我们设计了这样的订单履约流程：
public class OrderFulfillmentAppService { public void fulfillOrder(OrderId orderId) { // 1. 获取订单 Order order = orderRepository.findById(orderId); // 2. 检查库存 inventoryService.checkStock(order); // 3. 创建运单 Shipping shipping = shippingService.createShipping(order); // 4. 更新订单状态 order.markAsFulfilled(shipping.getId()); orderRepository.save(order); // 5. 发送领域事件 eventPublisher.publish(new OrderFulfilledEvent(orderId)); } }这个案例展示了应用层的典型工作模式：它不包含具体业务规则，只是像指挥家一样协调各个领域对象完成任务。
3.2 事务边界控制
分布式系统中，应用层还要处理棘手的事务问题。我们的经验是：
- 尽量使用最终一致性
- 对强一致性需求采用Saga模式
- 每个应用服务方法都是一个事务边界
比如支付超时场景，我们会拆分为：
- 创建待支付订单（本地事务）
- 发起支付（调用第三方）
- 定时任务检查支付结果（补偿机制）
4. 基础设施层的解耦技巧
4.1 仓储模式的实现
仓储接口属于领域层，实现则放在基础设施层。这种依赖倒置是DDD的精妙之处。在Spring项目中，我们这样实现：
// 领域层 public interface OrderRepository { Order findById(OrderId id); void save(Order order); } // 基础设施层 @Repository public class OrderRepositoryImpl implements OrderRepository { @PersistenceContext private EntityManager em; @Override public Order findById(OrderId id) { return em.find(Order.class, id); } }特别注意：仓储应该以聚合根为单位进行操作，避免出现"OrderItemRepository"这种违反DDD原则的设计。
4.2 防腐层实践
当需要集成外部系统时，一定要建立防腐层。我们在对接物流系统时是这样做的：
- 在领域层定义ShippingGateway接口
- 在基础设施层提供RestShippingGateway实现
- 对外部数据模型进行转换，适配我们的领域模型
这样当物流API变更时，只需修改基础设施层的实现，领域层代码完全不受影响。
5. 分层边界的守护策略
5.1 架构守护测试
随着项目规模扩大，分层架构容易腐化。我们引入了ArchUnit来编写架构测试：
@ArchTest static final ArchRule layer_dependencies_are_respected = layeredArchitecture() .layer("Interface").definedBy("..interfaces..") .layer("Application").definedBy("..application..") .layer("Domain").definedBy("..domain..") .layer("Infrastructure").definedBy("..infrastructure..") .whereLayer("Interface").mayNotBeAccessedByAnyLayer() .whereLayer("Application").mayOnlyBeAccessedByLayers("Interface") .whereLayer("Domain").mayOnlyBeAccessedByLayers("Application", "Interface");这套测试在CI流程中运行，有效防止了架构退化。
5.2 包结构设计
合理的包结构能强化分层意识。推荐按功能模块划分顶层包，再按层级划分子包：
com └── example └── order ├── application ├── domain │ ├── model │ ├── service │ └── repository └── interfaces ├── web └── rpc这种结构比传统的按层级划分更符合领域驱动设计的理念。
6. 从单体到微服务的演进
当系统需要拆分为微服务时，DDD分层架构展现出独特优势。我们的迁移步骤是：
- 通过事件风暴识别限界上下文
- 为每个上下文建立独立的分层架构
- 使用领域事件进行上下文集成
- 逐步将共享内核拆分为独立服务
在这个过程中，清晰的分层边界使得每个服务都能保持内聚，而应用层则成为服务间协调的自然场所。