DDD理论学习系列(3)-- 限界上下文

1. 引言

限界上下文可以拆分为两个词,限界和上下文。
限界:是指一个界限,具体的某一个范围。
上下文:个人理解就是语境。

比如我们常说的段子:

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

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

2. 案例分析

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

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

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

3. 限界上下文的命名

限界上下文只是一个统一的命名,在我们划分子域后,每个子域一般对应一个上下文,也可以对应多个上下文。但如果子域对应多个上下文的时候,就要考虑一下是不是子域能否继续划分。
命名方式很简单,领域名+上下文。
比如我们的销售子域对应销售上下文,物流子域对应物流上下文。

4. 总结

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

posted @ 2017-05-20 08:35 「圣杰」 阅读(...) 评论(...) 编辑 收藏