DDD领域驱动设计-限界上下文

限界上下文（bounded context）用来封装通用语言和领域对象，提供上下文环境，保证在领域之内的一些术语、业务相关对象等有一个确切的含义，没有二义性。这个边界定义了模型的适用范围，使团队所有成员能够明确地知道什么应该在模型中实现，什么不应该在模型中实现。

问题空间和解决方案空间

领域中同时存在问题空间和解决方案，问题空间中，我们考虑的是业务所面临的挑战，在解决方案空间中，我们思考的是如何通过技术来解决这些业务挑战

• 问题空间(Problem Space）

  是领域的一部分，对于问题空间的开发将产生一个新的核心域，对于问题空间的评估应该同时要考虑已有的子域和额外所需的子域，因此问题空间是核心域和其他子域的组合。

• 解决方案空间(Solution Space）

  包括了一个或者多个限界上下文，即一组特定的软件模型，这是因为限界上下文就是一个特定的解决方案，因为它能够通过技术的方式来实现解决方案。

根据以上的解释我们可以认为

1. 限界上下文规定了界限。

   这个界限包括语言含义的界限和模型的界限。应用的界限和技术的界限。

2. 限界上下文解决了问题

   我们通过一个或多个限界上下文，里面包括了聚合、实体、值对象、领域事件、领域服务等，能够解决实际的业务需求。

如何识别限界上下文

一个限界上下文封装了一个相对独立子领域的领域模型和服务。

子域subdomain和限界上下文某种意义上是互相印证的

这个时候我们通过事件风暴得到的领域模型就可以出场了。领域模型和子域都是从业务知识里分析得到的，将两者匹配起来可以再次验证我们对于业务的理解、子域的分解和领域模型是否合理。

为每个子域创建一个解决其问题的限界上下文，然后为每个领域模型找到其归属的限界上下文。每个领域事件都是为了解决某个问题，它和它相关的领域模型就应该放在这个问题子域对应的限界上下文里。

比如“活动已上线“这个事件，由运营人员在配置时触发，会导致用户可以开始参与活动。那么这个事件及其对应的“活动”概念应该被分为两个模型，分别归属于活动配置子域对应的“活动配置上下文”和活动子域对应的“活动上下文”。

为领域模型寻找归属完成后，我们会发现这么几个情况。

• 同一个概念可能会出现在多个限界上下文中。发生这种情况很正常，说明这多个子域都需要这个概念，而且很可能不同子域的领域模型不完全相同。

  比如刚才说到“活动”既存在于“活动上下文”中，又在“活动配置上下文”中。这里我们就很好的识别出了“重复的概念”问题。

• 也有一些概念重复在多个限界上下文中，这些概念和该上下文的主题并没有紧密的关系。这些模型可以单独出一个限界上下文，用以同时支撑多个限界上下文，以减轻限界上下文的负担。

• 有时候某个模型找不到合适的限界上下文，说明很可能是遗漏了一个子域，那就需要回到“分解子域”步骤，重新审视产品愿景。

聚合分组法采用“相关性”来划分限界上下文，其问题在于缺少一个主题，而子域恰好可以用来提供这个主题。本文的“愿景”-“核心域”-“周边子域”方法，不是唯一分解问题域的方法，任何可以将领域分解成高内聚低耦合的子域的方法都是可行的方法。

限界上下文示例：