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分层架构展现出独特优势。我们的迁移步骤是：

通过事件风暴识别限界上下文
为每个上下文建立独立的分层架构
使用领域事件进行上下文集成
逐步将共享内核拆分为独立服务

在这个过程中，清晰的分层边界使得每个服务都能保持内聚，而应用层则成为服务间协调的自然场所。

DDD分层架构实战：从理论到落地的关键设计