DDD领域驱动设计：概念解析

概念

DDD概念太多了，这里就一一拆解。

战略建模（Strategic Modeling）和战术建模（Tactical Modeling）

• 战略建模
  界限上下文（Bounded Context）、上下文映射图（Context Mapping）。
• 战术建模
  聚合（Aggregate）、实体（Entity）、值对象（Value Objects）、资源库（Repository）、领域服务（Domain Services）、领域事件（Domain Events）、模块（Modules）

在项目之初，领域专家和开发人员的工作就是探讨限界上下文的划定，这个非常重要，如果限界上下文的划定有问题，那么将来战术建模的进行将“一塌糊涂”，战术建模可以理解为战略建模的实现，前提是界限上下文都已经划定好，并确定无误。

问题空间（Problem Space）和解决方案空间（Solution Space）

• 问题空间
  我们思考的业务所面临的问题和挑战
• 解决方案空间
  我们思考的是如何实现软件以解决这些业务挑战

解决方案空间包含的内容很多，它是什么的解决方案？其实就是针对问题空间的解决方案，当问题空间被确定下来后，我们就会对核心域以及其他子域进行探讨和实施，然后在其中划分出很多的限界上下文，并用软件的方式进行实现。如果这样进行思考，你会发现，问题空间和解决方案空间对应于战略建模和战术建模，他们之间是有一些相似处，比如一个是探讨、战略，一个是实施、实现。

领域

这里引用北理工金旭亮老师的解释，感觉比较通俗易懂：“领域与具体开发技术无关。就是你的软件系统要解决的实际问题相关的所有东西的集合“。我们可以理解为业务领域，某一个专业的业务范围，可以非常大，比如电商，也可以非常小，比如订单系统，领域是一个抽象的概念，与业务结合。

子域

子域是领域更细粒度的划分，根据重要性与功能将领域分为大致三类（视项目实际情况而定）的多个子域，分别是核心子域、支撑子域和通用子域。

• 核心域
  核心域是业务成功的主要促成因素，主要竞争力，大白话就是这是服务的核心内容，商品域的核心就是商品，但可能需要其他来支撑。
• 支撑子域
  支撑子域是支撑核心域的
• 通用子域
  通用子域是业务系统的公用部分

限界上下文（Bounded Context）

定义：战略设计中确定语义所在的领域边界就是限界上下文，文字拆解：

• 限：划分、限定
• 界：界限、范围、分界
• 上下文：业务的整个流程

这样来看这个词，解释就是：为一个业务划清界线、范围，这个就类似微服务，拆解服务，我们可以把一个领域服务当作限界上下文。结合通用语言，我们就可以描述为：在一个特定的限界上下文只使用一套通用语言，并且保证它的清晰性和简洁性。限界上下文是微服务拆分和设计的主要边界依据，当然微服务还有其他的划分边界依据，需要综合考虑；我们将限界上下文内的领域模型映射到微服务就完成了从问题域到软件的解决方案。实际中限界上下文包含的是一个系统、一个应用、一种业务服务以及一系列实现业务的复杂组件。

谈谈实践

• 事件风暴
  通过事件风暴来确定领域边界，其中的需求提出者和技术实践者要共同完成领域建模，双方共同从系统事件的角度出发，提取可以反应系统运作的业务模型，进一步识别模型之间的关系，划分出限界上下文。

参考博客

理解限界上下文
领域驱动设计学习：领域、子域、限界上下文