第一篇　开篇

开篇，明义。

领域驱动设计（domain-driven design，DDD）需要应对软件复杂度的挑战！那么，软件复杂度的成因究竟是什么，又该如何应对？概括而言，即：

• 规模——通过分而治之控制规模；
• 结构——通过边界保证清晰有序；
• 变化——顺应变化方向。

领域驱动设计对软件复杂度的应对之道可进一步阐述为：

• 规模——以子领域、限界上下文对问题空间与解空间分而治之；
• 结构——以分层架构隔离业务复杂度与技术复杂度，形成清晰的架构；
• 变化——通过领域建模抽象为以聚合为核心的领域模型，响应需求之变化。

子领域、限界上下文、分层架构和聚合皆为领域驱动设计的核心元模型，分属战略设计和战术设计，贯穿了从问题空间到解空间的全过程。

领域驱动设计的开放性是其生命长青的基石，但它过于灵活的特点也让运用它的开发团队举步维艰。我之所以提出领域驱动设计统一过程，正是要在开放的方法体系指导之下，摸索出一条行之有效的软件构建之路，既不悖于领域驱动设计之精神，又不吝于运用设计元模型，通过提供简单有效的实践方法，建立具有目的性和可操作性的构建过程。

领域驱动设计统一过程分为3个阶段：

• 全局分析阶段；
• 架构映射阶段；
• 领域建模阶段。

每个阶段的过程工作流既融合了领域驱动设计既有的设计元模型，又提出了新的模式、方法和实践，丰富了领域驱动设计的外延。领域驱动设计统一过程对项目管理、需求管理和团队管理也提出了明确的要求，因为它们虽然不属于领域驱动设计关注的范畴，却是保证领域驱动设计实践与成功落地的重要因素。

领域驱动设计统一过程是对领域驱动设计进行解构的核心内容！