软件的核心，是为其用户解决领域相关问题的能力。
何为DDD
DDD是Domain Driven Design的简称。领域驱动设计，“领域”指业务领域，“设计”指软件设计。
DDD可以看成一种开发思想体系，促成了一种新的以领域为中心的思维方式，使得团队可以高效管理——用于复杂问题域的软件的构造和维护。
为什么DDD
对于一个复杂业务系统，无视业务复杂度而割裂式地进行软件设计，往往会造成软件的大泥球模式（BBoM），后果就是：
- 对统一语言和问题域知识缺乏重视，导致代码库可用但无法揭示业务意图。
- 缺乏基于问题域模型的应用程序设计的重视，让代码库缺乏与业务行为的协同效应，当有后续功能的扩展就会变得棘手。领域复杂性和技术复杂性混合在了一起。
- 会扼杀开发。对开发人员来说，软件杂乱、变更易出错。对企业来说，降低了软件快速实现商业价值的能力。
- 缺乏对问题域的关注和正确认识，构建出来的软件系统往往会失败。
注：问题域 ，涉及你当前正在构建软件的主题领域。是确定软件价值的关键点。
DDD模式
DDD具有两种模式类型：战略模式和战术模式。
战略模式影响的是解决方案，战术模式用于实现富领域模型。
Domain Drive Design Summary.png
DDD战略模式
领域驱动设计的战略模式会提炼问题域并塑造应用程序的架构。
- 提炼问题域以揭示重要之处是什么 —— 核心子域。核心域是编写软件的原因，保留最大价值的关键区域，决定软件成功与否的关键。并非一个系统的所有部分都需要被精心设计，团队可以更专注于核心领域。
- 在解空间构建一个软件模型，以处理领域问题并让软件与业务保持一致。
- 运用统一语言（Ubiquitous Language），开启建模协作。首先，确保的是领域专家和开发团队协作工作，其次，是将分析模型绑定到代码模型，以便开发团队和领域专家能够在模型设计方面进行协作。
- 限界上下文（Bounded Context），定义了模型的适用性并确保保留其完整性和独立发展的能力。统一语言和模型的适用边界应该是要在具体的限界上下文内。
- 上下文映射（Context Map）。上下文映射提供了整个系统各上下文边界之间的宏观状况，揭示了上下文之间的关系和交互方式，同时表现出各上下文内模型的有多少差异，以及它们的交换哪些数据来实现业务处理过程。
问题空间 & 解空间
战略模式中强调问题空间和解空间的区别。只有明确确定了问题空间，才能分析出对应的解空间，最终才能构建出满足解决业务问题的成功软件。
上1，是解决问题空间复杂度的管理模式。问题空间将问题提炼成更多可管理的子域。
上2、3、4、5， 是解空间的管理模式。
战略模式强调了DDD的侧重点是：知识消化、知识提炼、协作沟通、统一语言、上下文、模型持续发展。
后面战术模式，其实只是支持其实现而推荐的手段。
DDD战术模式
DDD的战术模式（也称模型构造块）是一个帮助创建用于复杂有界上下文的有效模型的模式集合。
许多模式都早于DDD概念的出现，但依然有一些被推荐为DDD战术的标准模式。
在战略模式提供的架构和原则的基础上，共用这些标准模式可以让设计有序进行，也使项目组成员能够更方便地了解彼此的工作内容。
- 实体（Entity）
- 值对象（Value Object）
- 领域服务（Domain Service）
- 工厂(Factory)和验证器(Validator)
- 聚合(Aggregation)
- 资源库(Repository)
- 领域事件(Domain Event)
- 模块(Module)
- 集成限界上下文
- 六边形架构
参考文献
- 《领域驱动设计：软件核心复杂性应对之道》，Eric Evans 著
- 《实现领域驱动设计》，Vaughn Vemon 著
- 《领域驱动设计模式、原理与实践》，Scott Millett / Nick Tune 著
