DDD理论学习系列（3）-- 限界上下文

1. 引言

限界上下文能够拆分为两个词，限界和上下文。
限界：是指一个界限，具体的某一个范围。
上下文：我的理解就是语境。

好比咱们常说的段子：

“我想静静。”
这个句子通常是想表达“我想静一静”的意思。可是咱们却把它玩笑成“静静是谁？”。
可见上下文语境很重要。

这个例子只是个开胃菜，咱们接着往下看。

2. 案例分析

整个应用程序以内的一个概念性边界。
边界以内的每种领域术语、词组或句子--也即通用语言，都有肯定的上下文含义。
边界以外，这些术语可能表示不一样的意思。

每次看到这种解释就头大。咱们仍是结合咱们的案例来聊一聊吧。

根据上一节对领域的剖析，咱们把案例主要拆分红几个子域，其中销售子域是核心域，商品子域和物流子域为支撑子域。在这三个子域中，都要和商品打交道。若是把商品抽象为Product对象的话，按咱们通常的常规思路（抛开子域的划分）来讲，无论是商品销售仍是发货，咱们均可以共用同一个Product对象。
但在DDD中，在商品子域和销售子域中，能够共享这个Product对象，但在物流子域，就有点大材小用。为何呢？由于毕竟物流子域关注的是商品的发货处理和物流跟踪。针对发货流程而言，我只关心商品的数量、大小、重量等规格，而没必要了解商品的价格等其余信息。因此说物流子域应该关注的是货物的发货处理而不是商品。
那为何咱们以前的开发思路会共用同一个Product对象呢？
答案很简单，没有进行领域的划分。把整个项目一律而论，统一建模致使的结果。
在DDD的思想下，当划分子域以后，每一个子域都对应有各自的上下文。在销售子域和商品子域所在的上下文语境中，商品就是商品，无二义性。在物流子域的上下文语境中，咱们也能够说商品的发货处理，但这时的商品就特指货物了。肯定了真实面目以后，我想咱们也会不禁自主的抽象一个新的Cargo对象来处理物流相关的业务。这也是DDD带来的好处，让咱们更清晰的建模。

3. 限界上下文的命名

限界上下文只是一个统一的命名，在咱们划分子域后，每一个子域通常对应一个上下文，也能够对应多个上下文。但若是子域对应多个上下文的时候，就要考虑一下是否是子域可否继续划分。
命名方式很简单，领域名+上下文。
好比咱们的销售子域对应销售上下文，物流子域对应物流上下文。

4. 总结

经过咱们上面的举例分析，限界上下文也并非一个高深的概念。
用官话来讲限界上下文主要用来封装通用语言和领域对象。
按我我的的理解它就是用来为领域提供上下文语境，保证在领域以内的一些术语、业务相关对象等（通用语言）有一个确切的含义，没有二义性。