通用语言和限界上下文

DDD领域建模和系统建设过程中，领域专家、产品经理、项目经理、架构师、开发经理和测试经理都会参与。为了理解和交流的障碍，DDD中出现了“通用语言”和“限界上下文”两个重要概念。

通用语言定义上下文含义，限界上下文定义领域边界。

什么是通用语言
    在事件风暴过程中，通过团队交流达成共识的，能够简单、清晰、准确描述业务含义和规则的语言就是通用语言。通用语言是团队统一的语言，可以解决交流障碍的问题。

    通用语言包含属于和用例场景，且能够直接反映在代码中。其中的名词可以给领域对象命名，如商品、订单等，对应实体对象；动词则表示一个动作或事件，如下单、付款等，对应领域事件。其贯穿DDD的整个设计过程。

 
上图描述了从事件风暴建立通用语言到领域对象设计和代码落地的完成过程：

1.事件风暴的过程中，领域专家、设计、开发一起建立领域模型，建模过程中会形成通用的业务属于和用户故事。这是团队统一语言的过程。

2.通过用户故事分析会形成一个个领域对象，并对应领域模型的业务对象，每一个业务对象和领域对象是一一映射的。

3.微服务代码模型来源于领域模型，每个代码模型的代码和领域对象一一对应。

    设计过程中可以用一些表格，来记录事件风暴和微服务设计过程中产生的领域对象及其属性。比如领域对象在DDD分层架构中的位置、属性、依赖关系以及与代码模型对象的映射关系等。如：

 
DDD分析和设计的每一个环节都保证限界上下文内术语的统一，在代码模型设计的时候就要建立领域对象和代码对象的一一映射，保证业务模型和代码模型的一致，实现业务语言与代码语言的统一。

什么是限界上下文
通用语言有它的上下文环境。“限界上下文”用来确定通用语言所在的领域边界。
限界、和上下文：限界就是领域的边界，上下文则是语义环境。
限界上下文的定义：用来封装通用语言和领域对象，提供上下文环境，保证在领域内的一些术语、业务相关对象等（通用语言）有一个确切的含义，没有二义性。这个边界定义了模型的适用范围。

进一步理解限界上下文：
举个例子：
孩子问妈妈：今天应该穿几件衣服？妈妈说：能穿几件穿几件。
到底穿多还是穿少？
如果可以知道这句话的语义环境，炎炎夏日或寒冬腊月，那就能理解了。所以语言离不开它的语义环境。

而业务的通用语言就有它的业务边界，不大可能用一个简单的术语没有歧义的描述一个复杂的业务领域。限界上下文就是用来细分领域，定义通用语言所在的边界。

用一个保险领域的例子来说明：保险业务又投保单、保单、批单、赔案等专业术语，分别对应保险的不同业务流程：

1、客户投保时，记录投保信息，系统对应有投保单bean；
2、缴费完成后，投保单转为保单，系统对应有保单bean，保单bean与投保单bean关联；
3、如需要修改保单信息，保单变为批单，系统对应有批单bean，批单bean与保单bean关联；
4、如果发生理赔，生成赔案，系统对应有赔案bean，赔案bean与保单bean或批单备案关联。

投保单、保单、批单、赔案等，虽然都有保单有关，但不能将保单这个术语作用在保险全业务领域，因为术语有它的边界。

    正如电商领域的商品，在销售阶段是商品，在运输阶段则变成了货物。同样的东西，因为业务领域不同，赋予了这些术语不同的涵义和指责边界，这个边界可能就会成为未来微服务设计的边界。领域边界就是通过限界上下文来定义的。

限界上下文和微服务的关系
    车险承保的流程包含了投保、缴费、出单等流程，如果出险还会有报案、查勘、定损、理算等。

用一个简单的保险模型来说明下届上下文和微服务的关系：

 

首先，保险领域被拆分为投保、支付、保单管理、理赔四个子域。

子域还可以根据需要进一步拆分为子子域，到一定程度后，有些子子域的领域边界可能就变成限界上下文的边界了。子域可能包含多个限界上下文，如理赔包含报案、查看、定损等（限界上下文和理赔的子子域领域边界重合），也有可能子域本身的边界就是限界上下文边界，如投保子域。

理论上限界上下文就是微服务的边界。将限界上下文内的领域模型映射到微服务，就完成了从问题域到软件的解决方案。

限界上下文是微服务拆分的主要依据，如果不考虑其他外部因素，领域模型中一个限界上下文就是可以设计为一个微服务。当然，这只是理论，微服务的拆分有很多限制因素，设计中不宜过度拆分。

每个领域都有其对应的限界上下文，团队在限界上下文内用通用语言交流。领域内所有限界上下文的领域模型构成整个领域的领域模型。

 
 
 
 
 
 
 
 

---

参考文档：
https://www.cnblogs.com/junzi2099/p/13682028.html