【DDD系列-9】DDD最详细概念参考

1 通用类概念​

1.1 领域驱动设计（DDD）​

DDD 是 Domain-Driven Design 的缩写，是 Eric Evans 于 2004 年提出的一种软件设计方法和理念。​

其主要的思想是，利用确定的业务模型来指导业务与应用的设计和实现。主张开发人员与业务人员持续地沟通和模型的持续迭代式演化，以保证业务模型与代码实现的一致性，从而实现有效管理业务复杂度，优化软件设计的目的。​

1.2 模型（Model）​

通常，模型是对对象、人或系统的信息表示。它通过较为简单的信息结构来代表我们需要理解的复杂事物或系统。​

地图、乐高、算筹都是模型，模型可以简化复杂事务的认知。我们天生就有用简单的东西代表另外一个东西的能力，比如幼儿园数数用的竹签，学习物理时的刚体、真空中的球形鸡，都是模型。通俗来说模型就是经验的抽象集合，平时听到的谚语、公式、定理，本质上都是一种模型。

1.3 建模（Modeling）​

建模是构建模型的过程。​

在软件设计过程中，通过分析业务，将业务需求使用合适的模型表示出来，是建模的任务。模型可以作为业务分析的产出，并作为软件设计的重要理论基础。 比如在分析一个电商应用的业务时，抽象出订单、商品等概念，进一步定义出模型，并用合适的图例表达，往往是 UML 来表达。​

1.4 模型驱动设计（Model-Driven Design）​

面向模型的分析设计方法，优先通过识别模型来简化业务设计。​

在设计过程中，以模型为中心，始终维护模型，并基于此指导软件设计。​

1.5 软件设计（The Software Design）​

软件设计软件需求出发，对软件系统的整体结构、模块做出划分和规划，以便于具体代码的顺利编写。​

由于软件需求具有非结构化、准确的语义，软件设计往往通过经验完成，无法通过某种特定的推理路线严格推导实现。​

1.6 战略设计（Strategic Design）​

战略设计也称为战略建模，是指对业务进行高层次的抽象和归类。主要手段包括理清上下文和进行子域的划分。​

战略设计关注模型的分离，其解决的问题是大的模型如何划分为小模型以及相互之间如何关联。战略设计的产出可以用于指导团队协作，使得规模巨大的软件可以被合理拆分。​

战略设计的产出通常为上下文图，以及模块或微服务划分。​

1.7 战术设计（Tactical design）​

战术设计也称为战术建模，是指对特定上下文下的模型进行详细设计。​

战术设计的对象包括聚合、实体和值对象，其目标是用明确它们是什么以及相互之间有何关系。战术设计的产出可以是用 UML 表达的类图，需要细化到具体的属性，同时确保在代码级别可实现。​

1.8 软件（Software）​

DDD 讨论下的软件是指，用于解决具体业务问题的计算机程序，既可以是单体也可以是分布式系统。​

软件设计是 DDD 的最终目的，使用 DDD 的各种工具可以指导软件设计，最终构建出健壮、容易维护的软件。

1.9 原则（Principle）​

为了更好的践行 DDD，需要遵守几个原则: 通用语言、聚焦核心域、协作共创和持续建模。​

这些原则是为了更好地服务业务，从业务驱动模型设计。​

1.10 通用语言（Ubiquitous）​

通用语言（Ubiquitous language）是指在软件设计中，业务人员和开发人员需要使用无歧义的统一语言来对话。​

这些语言包括对概念的统一理解和定义，以及业务人员参与到软件建模中，否则业务的变化会造成软件巨大的变化。​

1.11 聚焦核心域（Focus）​

核心域就是最关键的业务逻辑，聚焦核心域决定了软件的定位和投资重心。​

1.12 协作共创（Collaboration）​

协作共创是指领域专家和业务专家共同建模。​

1.13 持续建模（Continuous）​

持续建模是指模型需要随业务变化而被及时更新。​

1.14 上下文（Context）​

上下文是语言学科的概念，指不同语境下的概念虽然相同的用词，可能具有不同的含义。​

在软件设计中，因为自然语言的原因，相同的用词导致实际是不同概念，会对建模和软件设计带来误导。同时，不同的上下文也是识别模型边界的手段。

2 领域分析类概念​

2.1 问题空间（Problem Space）​

待解决的业务问题的集合。​

在 DDD 实践中，我们应该明确区分问题空间和解空间，避免混