电子监管码设备
DDD领域驱动实战（⼆）-限界上下⽂（boundedcontext） 限界上下⽂定义领域边界，以确保每个上下⽂含义在它特定的边界内都具有唯⼀含义，领域模型则存于该边界内。 通⽤语⾔
定义
事件风暴过程中，通过团队交流达成共识的，能够简单、清晰、准确描述业务涵义和规则的语⾔。限界上下⽂中的通⽤语⾔提供了设计领域模型的概念术语。
通⽤语⾔是必须通过与领域专家详细讨论后才得到的统⼀语⾔，不管你在团队承担什么⾓⾊，在同⼀领域的软件⽣命周期⾥都使⽤统⼀语⾔交流。通⽤语⾔定义上下⽂含义，可解决交流障碍，使领域专家和开发⼈员能够协作，从⽽确保业务需求的正确表达。
组成
通⽤语⾔包含术语和⽤例场景，能够直接反映在代码。通⽤语⾔中的 体验台名词
形容词
描述这些概念
动词
表⽰可完成的操作，⽐如⼀个动作或事件，如商品已下单、订单已付款，对应领域事件或命令
通⽤语⾔贯穿DDD。基于它，代码可读性更好，最后能将业务需求准确转化为代码设计。
1. 事件风暴时，领域专家会和设计、开发⼈员⼀起建⽴领域模型，在领域建模过程中形成通⽤的业务术语和⽤户故事，这也是⼀个项⽬
团队统⼀语⾔的过程
2. 通过⽤户故事分析会形成⼀个个领域对象，这些领域对象对应领域模型的业务对象，每⼀个业务对象和领域对象都有通⽤的名词术
语，并且⼀⼀映射
3. 微服务代码模型源于领域模型，每个代码模型的代码对象跟领域对象⼀⼀对应
可以表格记录事件风暴和微服务设计过程中产⽣的领域对象及属性。⽐如，领域对象在DDD分层架构中的位置、属性、依赖关系以及与代码模型对象的映射关系等。
DDD分析和设计过程中的每⼀个环节都需要保证限界上下⽂内术语的统⼀，在代码模型设计的时侯就要建⽴领域对象和代码对象的⼀⼀映射，从⽽保证业务模型和代码模型的⼀致，实现业务语⾔与代码语⾔的统⼀。风送系统
做到这点，就建⽴了领域对象和代码对象的映射关系，即可指导开发准确⽆误按设计⽂档完成微服务开发。即使是不熟悉代码的业务⼈员，也可很快到代码位置。
桥架接头限界上下⽂
限界上下⽂就是⽤以确定语义所在的领域边界。就可在统⼀的领域边界内⽤统⼀的语⾔进⾏交流。
封装通⽤语⾔和领域对象，提供上下⽂环境，保证在领域之内的⼀些术语、业务相关对象等（通⽤语⾔）⽆⼆义性。
这个边界定义了模型的适⽤范围，使团队所有成员能够明确地知道什么应该在模型中实现，不应该在模型中实现。
案例
业务的通⽤语⾔也有它的业务边界。限界上下⽂就是⽤来细分领域，从⽽定义通⽤语⾔所在的边界。
如电商领域的商品，商品在不同阶段有不同术语：
销售阶段是商品
运输阶段则变成货物
同⼀个东西，由于业务领域不同，赋予了这些术语不同涵义和职责边界，这个边界就可能会成为未来微服务设计的边界。领域边界就是通过限界上下⽂来定义的。
银行复点机
限界上下⽂和微服务
⼦域还可根据需要进⼀步拆分为⼦⼦域。如⽀付⼦域，继续拆为收款、付款⼦⼦域。拆到⼀定程度后，有些⼦⼦域的领域边界可能变成限界上下⽂的边界了。
⼦域可能会包含多个限界上下⽂。
如理赔⼦域就包括报案、查勘和定损等多个限界上下⽂（限界上下⽂与理赔的⼦⼦域领域边界重合）。
也有可能⼦域本⾝的边界就是限界上下⽂边界，如投保⼦域。
每个领域模型都有它对应的限界上下⽂。领域内所有限界上下⽂的领域模型构成整个领域的领域模型。
理论上限界上下⽂就是微服务的边界。我们将限界上下⽂内的领域模型映射到微服务，就完成了从问题域到软件的解决⽅案。
限界上下⽂是微服务设计和拆分的主要依据。
在领域模型中，如果不考虑技术异构、团队沟通等因素，⼀个限界上下⽂理论上就可以设计为⼀个微服务。
豫公网安备41160202000603
站长QQ:729038198
关于我们
投诉建议