【DDD】领域驱动设计中的限界上下文

承接上文，我们知道了，在确定好研究的领域后，我们可以进行粗粒度的拆分，可以将领域拆分成不同的子域，不同的子域又承担着不同的业务职责，根据重要性，可以将子域分为 核心域、支撑域和通用域，一般来说，我们要将重点放到核心域的开发与集成上。

在DDD中，一个领域被分为若干子域，领域模型是在特定的场景中来设计的，这个场景固定了业务的范围，固定了一致的语言。

限界上下文的初体验

什么是限界上下文

对应于通用语言，限界上下文是语言的边界，对于领域模型，限界上下文是模型的边界，二者对应于问题空间（Problem Space）的界定。 对于系统的架构，限界上下文还确定了应用边界和技术边界，进而帮助我们确定整个系统及各个限界上下文的解决方案。 可以说，限界上下文是连接问题空间与解决方案空间的重要桥梁。

这个时候又引申除了两个词，也就是问题和解决方案空间，我们来看一下。

问题空间和解决方案空间

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

• 问题空间(Problem Space）

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

• 解决方案空间(Solution Space）

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

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

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

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

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

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

限界上下文的实操

首先先来一张图，让大家对限界上下文有一个直观的感受

下面我将仓报价系统拆为以下几个子域和限界上下文。

• 核心域：价格计算限界上下文

• 支撑域：库存变更消息转换限界上下文、SPI限界上下文、wms限界上下文

• 通用域：数据校验限界上下文

注：我无法将所有的限界上下文全部列出，只列出了类似于敏捷开发中的MVP。只是为了说明本节讨论的问题。

一般来说，一个子域对应着一个限界上下文是比较合适的，但是，有些场景下并一定非要这样不可。

1. 首先，对于核心域来说，一定是我们系统最重要的功能，我们系统就是为了计算成本价格，所以计算价格的限界上下文一定是属于核心域。

2. 我们系统承接wms的mq消息，对于我们系统来说，接谁的消息不重要，重要的是把消息转换为我们仓报价系统能够识别的语言。所以接收消息进行语言转换，对我们来说是支撑域。同时，对于SPI来说，我们需要RPC或者其他方式来建立与其他系统的数据沟通渠道，获取一些我们认为重要的值，比如说，我们需要调用采购系统的服务，来提供给我们采购价，需要调用加工系统，来给我们返回加工的比例等等。所以对我们来说也是支撑域

3. 对于数据的准确性校验，一致性校验，传ebs数据的校验，这些都需要一定的规则来处理，为的是及时的预警出来，我们需要自己系统实现validate或者使用共用的validate组件，这不重要，重要的是对于我们系统来说，validate是一个与其他限界上下文都有紧密关系的限界上下文，但此处并不属于共享内核。只是一个通用域

结语

总之，业务场景不同，拆分的粒度不同，限界上下文是一个显式的边界，领域模型、领域服务、领域事件等就存在于边界之内，在边界内，通用语言中的所有术语都有特定含义，可以说，不同限界上下文中可能有同样的词汇，但是对于一个限界上下文内，不存在二义性。希望能够帮助大家理解好限界上下文

文章知识点与官方知识档案匹配，可进一步学习相关知识Java技能树首页概览92167 人正在系统学习中

来源：wangzy-nice