DDD领域驱动实战(二)-限界上下文(bounded context)

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

通用语言

定义

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

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

组成

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

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

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

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

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

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

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

限界上下文

限界上下文就是用以确定语义所在的领域边界。就可在统一的领域边界内用统一的语言进行交流。

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

案例

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

如电商领域的商品，商品在不同阶段有不同术语：

• 销售阶段是商品
• 运输阶段则变成货物

同一个东西，由于业务领域不同，赋予了这些术语不同涵义和职责边界，这个边界就可能会成为未来微服务设计的边界。领域边界就是通过限界上下文来定义的。

限界上下文和微服务

子域还可根据需要进一步拆分为子子域。如支付子域，继续拆为收款、付款子子域。拆到一定程度后，有些子子域的领域边界可能变成限界上下文的边界了。

子域可能会包含多个限界上下文。 如理赔子域就包括报案、查勘和定损等多个限界上下文（限界上下文与理赔的子子域领域边界重合）。也有可能子域本身的边界就是限界上下文边界，如投保子域。

每个领域模型都有它对应的限界上下文。领域内所有限界上下文的领域模型构成整个领域的领域模型。 理论上限界上下文就是微服务的边界。我们将限界上下文内的领域模型映射到微服务，就完成了从问题域到软件的解决方案。

限界上下文是微服务设计和拆分的主要依据。 在领域模型中，如果不考虑技术异构、团队沟通等因素，一个限界上下文理论上就可以设计为一个微服务。