【实践篇】领域驱动设计：DDD工程参考架构 | 京东云技术团队

背景

为什么要制定参考工程架构

不同团队落地DDD所采取的应用架构风格可能不同，并没有统一的、标准的DDD工程架构。有些团队可能遵循经典的DDD四层架构，或改进的DDD四层架构，有些团队可能综合考虑分层架构、整洁架构、六边形架构等多种架构风格，有些在实践中可能引入CQRS解决读模型与写模型的差异化等等。即使无法制定通用的、标准的工程应用架构，但为团队制定一个遵循领域驱动设计思想的参考架构依然有价值。基于以下原因：

• 为团队实践DDD的战术设计提供可以快速开始的工程参考
• 参考工程大量的命名和结构决策，显式的体现DDD的相关理念，有利于团队对DDD的战术实现达成一致认知
• 同时，参考架构有助于沉淀团队对领域驱动设计的一些思考和最佳实践

参考架构的考量因素

虽然无法制定完全通用的DDD参考架构，但制定某个特定上下文下的参考架构却具有可行性和实践价值。针对于上下文的选择要尽量贴合实际的工程实践场景并考虑多维度的因素。

本文所述参考工程架构遵循以下原则：

• 遵循领域驱动设计的本质思想
• 充分考虑业务系统建设特点
• 依赖最小化，保持轻量

希望工程参考架构能涵盖以下范围

• 分离业务域与技术域

参考架构要遵循技术和业务隔离的特性，可以参考多种架构风格。业务与技术关注点的分离并不是DDD独有的特点，在六边形、整洁架构、洋葱架构中都遵循了这一重要原则。

• 多限界上下文场景

大多数团队基于DDD进行微服务拆分的时候，特别是系统建设初期，对单个微服务应用内的限界上下文的粒度需要权衡。由于团队组织架构因素及微服务成本问题，单个应用容纳的限界上下文一般是多个(理想情况下是1:1)。这些限界上下文随着后续的逐步迭代有可能会迁移至独立应用。因此，参考架构将多上