烂人不配爱1. 为什么我们需要DDD与整洁架构的结合
十年前我第一次接触领域驱动设计（DDD）时，被其战略设计中的限界上下文（Bounded Context）和战术设计中的聚合根（Aggregate Root）等概念深深吸引。但真正落地时却发现，即使团队对DDD理论倒背如流，代码库依然在半年后变成了"大泥球"。直到后来结合了整洁架构（Clean Architecture），才真正让DDD从理论走向了工程实践。
DDD解决的是业务复杂度问题，它通过统一语言（Ubiquitous Language）和领域模型（Domain Model）让技术人员和业务专家能够高效协作。而整洁架构解决的是技术复杂度问题，通过依赖倒置等原则保持核心业务逻辑的纯粹性。两者结合，就像给赛车装上了导航系统——既保证了引擎的高性能，又确保了行驶方向的正确性。
提示：在实际项目中，常见误区是过度关注DDD中的模式（如Repository、Factory），而忽略了领域模型才是核心。整洁架构的价值就在于保护这个核心不被技术细节污染。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 战略设计：用限界上下文划分业务疆域
2.1 从业务事件出发识别核心域
在电商系统中，我曾带领团队通过事件风暴（Event Storming）工作坊识别出"订单履约"是核心域。具体做法是：
- 邀请领域专家、产品经理、开发人员共同参与
- 用橙色贴纸标记所有业务事件（如"订单已创建"、"库存已预留"）
- 用红色贴纸标记命令（如"创建订单"、"扣减库存"）
- 最终通过事件流密度确定核心域
这个过程中最关键的收获是：不要试图一次性建模整个系统。我们最初犯的错误就是把"用户评价"和"订单履约"放在同一个限界上下文中，导致两者都难以演进。
2.2 上下文映射的实战模式选择
上下文映射（Context Map）有至少六种模式，但在实际项目中，这三种最为常见：
| 模式 | 适用场景 | 我们项目的选择依据 |
|---|---|---|
| 合作关系 | 两个团队强耦合且同步演进 | 用于支付与订单的结算流程 |
| 客户-供应商 | 下游依赖上游但上游不关心下游 | 物流系统作为订单系统的客户 |
| 防腐层 | 需要隔离遗留系统或第三方服务 | 对接旧版ERP系统时采用 |
在物流跟踪功能中，我们最初错误地选择了"共享内核"模式，导致订单系统被迫承载物流状态变更的逻辑。后来通过引入"反腐层"（Anticorruption Layer）进行重构：
java复制// 订单服务中的物流防腐层示例
public class LogisticsAdapter {
private LogisticsServiceClient client;
public TrackingInfo translateTracking(ExternalLogisticsDTO dto) {
// 在这里进行DTO转换和异常处理
return new TrackingInfo(dto.getStatus(), parseLocation(dto.getRawGps()));
}
}
3. 战术实现：整洁架构下的领域模型
3.1 四层架构的依赖关系控制
整洁架构最显著的特征是依赖规则：内层不依赖外层。在Java项目中，我们通过模块化实现这一点：
code复制order-service
├── domain (核心业务逻辑)
├── application (用例编排层)
├── infrastructure (持久化、消息等实现)
└── interfaces (API和DTO定义)
关键技巧是在domain模块中定义仓储接口，在infrastructure中实现。这样domain完全不知道持久化细节：
kotlin复制// domain层定义接口
interface OrderRepository {
fun findById(id: OrderId): Order?
}
// infrastructure层提供JPA实现
@Repository
class OrderJpaRepository : OrderRepository {
@Autowired
private lateinit var jpaRepo: JpaOrderRepository
override fun findById(id: OrderId) = jpaRepo.findById(id.value).map { it.toDomain() }
}
3.2 聚合设计的边界控制
聚合（Aggregate）是最容易过度设计的部分。我们的经验法则是：
- 通过业务不变式（Invariants）确定聚合根
- 单个聚合内的对象数量不超过10个
- 聚合引用其他聚合只通过ID
在订单模型中，最初将Order和OrderItem设计为两个聚合，结果发现维护一致性成本太高。后来调整为以Order为聚合根包含OrderItem的模型：
typescript复制// 正确的聚合设计示例
class Order {
private items: OrderItem[];
addItem(productId: string, quantity: number) {
if(this.items.some(i => i.productId === productId)) {
throw new Error("Duplicate product");
}
this.items.push(new OrderItem(productId, quantity));
}
}
4. 落地挑战与解决方案
4.1 持久化实现的陷阱
使用ORM框架时，最容易破坏领域模型的行为封装。我们曾遇到JPA的懒加载（Lazy Loading）导致的问题：
- 领域方法中意外触发N+1查询
- JSON序列化时意外加载关联对象
- 事务边界外访问延迟加载属性
解决方案是：
- 在application层明确加载策略
- 使用DTO而非直接暴露领域对象
- 对复杂查询采用CQRS模式
4.2 分布式事务的最终一致性
在订单扣减库存的场景中，我们最初采用2PC（两阶段提交），发现性能无法接受。后来改用Saga模式：
- 订单服务创建订单（状态为PENDING）
- 发布InventoryReservationRequested事件
- 库存服务处理成功后发布InventoryReserved事件
- 订单服务确认订单
补偿逻辑示例：
python复制def compensate_order(order_id):
order = repo.find(order_id)
if order.status == 'PENDING':
order.cancel()
repo.save(order)
publish(OrderCanceled(order_id))
5. 测试策略的调整
5.1 单元测试的重点转移
传统单元测试关注对象方法，在DDD中我们更关注领域行为：
javascript复制// 不好的测试：测试实现细节
test('should set productId when add item', () => {
order.addItem('p1', 2);
expect(order.items[0].productId).toBe('p1');
});
// 好的测试：测试业务规则
test('should reject duplicate products', () => {
order.addItem('p1', 1);
expect(() => order.addItem('p1', 2)).toThrow();
});
5.2 契约测试在上下文协作中的应用
当订单服务需要调用支付服务时，我们使用Pact进行契约测试：
- 订单服务定义期望的请求/响应
- 支付服务验证自身实现是否符合契约
- 在CI流程中自动验证
这比传统的集成测试更早发现接口兼容性问题。
6. 演进式架构的实践
6.1 从单体到微服务的渐进式拆分
我们不是一开始就采用微服务，而是：
- 单体中按限界上下文分包
- 将频繁变更的模块独立部署
- 最终拆分为独立服务
关键指标是模块间调用关系的变化频率。
6.2 领域模型的持续精炼
每次冲刺（Sprint）结束后，我们会：
- 检查新功能是否破坏了现有模型
- 识别新的领域概念
- 必要时进行模型重构
比如最初设计的Price概念后来拆分为BasePrice、Promotion和Tax三个模型。