DDD领域驱动设计-限界上下文bounded context

限界上下文定义领域边界，以确保每个上下文含义在它特定的边界内都具有唯一的含义，领域模型则存在于这个边界之内。

通用语言

在事件风暴过程中，通过团队交流达成共识的，能够简单、清晰、准确描述业务涵义和规则的语言。限界上下文中的通用语言向我们提供了设计领域模型的概念术语。

通用语言不是平白产生的，它必须通过与领域专家详细讨论之后才能得到的统一语言，不管你在团队中承担什么角色，在同一领域的软件生命周期里都使用统一的语言进行交流。通用语言定义上下文含义，它可解决交流障碍，使领域专家和开发人员能够协作，从而确保业务需求的正确表达。

通用语言包含术语和用例场景，能够直接反映在代码。通用语言中的

名词，用于给领域对象等概念命名，如商品、订单，对应实体对象
形容词，用于描述这些概念
动词，表示可以完成的操作，比如一个动作或事件，如商品已下单、订单已付款，对应领域事件或者命令

通用语言贯穿DDD。基于它，代码可读性更好，将业务需求准确转化为代码设计。

从事件风暴建立通用语言到领域对象设计和代码落地过程

在事件风暴的过程中，领域专家会和设计、开发人员一起建立领域模型，在领域建模的过程中会形成通用的业务术语和用户故事。事件风暴也是一个项目团队统一语言的过程
通过用户故事分析会形成一个个的领域对象，这些领域对象对应领域模型的业务对象，每一个业务对象和领域对象都有通用的名词术语，并且一一映射
微服务代码模型来源于领域模型，每个代码模型的代码对象跟领域对象一一对应。

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

下面是一个微服务设计实例的部分数据，表格中的这些名词术语就是项目团队在事件风暴过程中达成一致、可用于团队内部交流的通用语言。

DDD分析过程中所有的领域对象及它们的属性都被记录，除了领域对象，还记录了在微服务设计过程中领域对象所对应的代码对象，并一一映射。

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

做到这点，就建立了领域对象和代码对象的映射关系，即可指导开发准确无误按设计文档完成微服务开发。即使是不熟悉代码的业务人员，也可很快找到代码位置。

限界上下文

语言都有语义环境，通用语言亦是。为避免同样概念或语义在不同上下文环境中歧义，DDD在提出“限界上下文”，确定语义所在的领域边界。就可在统一的领域边界内用统一的语言进行交流。

就是封装通用语言和领域对象，提供上下文环境，保证在领域之内的一些术语、业务相关对象等（通用语言）有一个确切的含义，没有二义性。
这个边界定义了模型的适用范围，使团队所有成员能够明确地知道什么应该在模型中实现，不应该在模型中实现。

案例

都说汉语博大精深，不同的情境下，一个词会有不同涵义。比如小孩问妈妈：“今天应该穿几件衣服呀？”妈妈说：“能穿多少就穿多少！”那到底是穿多还是穿少？没有具体语境，还真不好判断。但若限定语境，比如寒冬或炎夏，就很清晰了。所以语言离不开它的语义环境。

业务的通用语言也有它的业务边界。限界上下文就是用来细分领域，从而定义通用语言所在的边界。

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

限界上下文和微服务

车险承保的流程包含了投保、缴费、出单等几个主要流程。如果出险了还会有报案、查勘、定损、理算等理赔流程。
保险领域被拆分为：投保、支付、保单管理和理赔四个子域。子域还可根据需要进一步拆分为子子域，比如，支付子域可继续拆分为收款和付款子子域。拆到一定程度后，有些子子域的领域边界就可能变成限界上下文的边界了。子域可能会包含多个限界上下文，如理赔子域就包括报案、查勘和定损等多个限界上下文（限界上下文与理赔的子子域领域边界重合）。也有可能子域本身的边界就是限界上下文边界，如投保子域。
每个领域模型都有它对应的限界上下文，团队在限界上下文内用通用语言交流。领域内所有限界上下文的领域模型构成整个领域的领域模型。理论上限界上下文就是微服务的边界。我们将限界上下文内的领域模型映射到微服务，就完成了从问题域到软件的解决方案。
限界上下文是微服务设计和拆分的主要依据。在领域模型中，如果不考虑技术异构、团队沟通等其它外部因素，一个限界上下文理论上就可以设计为一个微服务。
不过微服务的拆分还是有很多限制因素的，在设计中不宜过度拆分

总结

通用语言确定了项目团队内部交流的统一语言，而这个语言所在的语义环境则是由限界上下文来限定的，以确保语义的唯一性。
领域专家、架构师和开发人员的主要工作就是通过事件风暴来划分限界上下文。限界上下文确定了微服务的设计和拆分方向，是微服务设计和拆分的主要依据。如果不考虑技术异构、团队沟通等其它外部因素，一个限界上下文理论上就可以设计为一个微服务。

参考