(1). 引言
DDD的战略设计知识,来源于:极客时间
和(https://www.cnblogs.com/sheng-jie/p/6931646.html) DDD的战术设计知识来源于:https://github.com/citerus/dddsample-core.git (2). 什么是限界上下文
限界上下文可以拆分为两个词:限界和上下文.
限界:是指一个界限,具体的某一个范围. 上下文:个人理解就是语境.(3). 案例分析
有这样一个电商系统,拆分成了:商品子域/用户子域/销售子域/订单子域/支付子域/物流子域/客服子域…
其中:销售子域是核心域,商品子域和物流子域为支撑域.在这三个子域中,都要和商品打交道.
如果把商品抽象为Product类的话,按我们一般的常规思路来说,不管是商品销售还是发货,我们都可以共用同一个Product类.
在DDD中,在商品子域和销售子域中,可以共享这个Product对象,但在物流子域,就有点不适合了.为什么呢?
因为毕竟物流子域关注的是商品的发货处理和物流跟踪.针对发货流程而言,我只关心商品的数量、大小、重量等规格,而不必了解商品的价格等其他信息.所以说物流子域应该关注的是货物的发货处理而不是商品.
那为什么我们之前的开发思路会共用同一个Product对象呢?
答案很简单:没有进行领域的划分.把整个项目一概而论,统一建模导致的结果.
在DDD的思想下,当划分子域之后,每个子域都对应有各自的上下文.在销售子域和商品子域所在的上下文语境中,商品就是商品,无二义性.在物流子域的上下文语境中,我们也可以说商品的发货处理,但这时的商品就特指货物了.确定了真实面目之后,我想我们也会不由自主的抽象一个新的Cargo类来处理物流相关的业务.这也是DDD带来的好处,让我们更清晰的建模.(4). 限界上下文的命名
限界上下文只是一个统一的命名,在我们划分子域后,每个子域一般对应一个上下文,也可以对应多个上下文.但如果子域对应多个上下文的时候,就要考虑一下是不是子域能否继续划分.
命名方式很简单，领域名+上下文. 比如:销售子域对应销售上下文,物流子域对应物流上下文.(5). 总结
限界上下文用来为领域提供上下文语境,保证在领域之内的一些术语、业务相关对象等(通用语言)有一个确切的含义,没有二义性.
