共计 3196 个字符，预计需要花费 8 分钟才能阅读完成。
什么是通用语言
通用语言, 最次要的目标就是缩小交换中信息失落, 在理论开发中, 可能关联很多人, 例如有业务层面的业务细节制定者、领域专家、产品经理、项目经理、架构师、开发经理、测试经理等等, 即便确定了外围域, 然而对于同样的畛域常识, 每个人也有本人的了解, 举个例子, 咱们通常说的商品和货物, 是不是其实就是一个货色 ? 在销售畛域叫商品, 然而一旦进入物流畛域就叫货物, 所以咱们一说商品就晓得这是在销售子域, 一旦说货物就晓得这是在物流畛域, 如果只用物品来进行交换可能就会失落信息, 因为在不同的子域关注的重点是不同的, 为了缩小信息失落, 确保大家交换的便利性, 将可能简略清晰精确形容业务含意和规定的语言就是畛域通用语言, 也就是通用语言是团队对立的语言, 只有你在这个畛域, 那么在一个零碎生命周期内就应该用通用语言进行交换。
可见, 通用语言作用还是很清晰明了的, 解决沟通阻碍节省时间老本, 让大家更好进行合作, 通用语言蕴含术语与利用场景, 并且可能反映在代码中, 例如给畛域对象命名, 如商品、订单等, 对应实体对象; 而动词则示意一个动作或者事件, 例如商品曾经下单, 订单已付款, 运输中等等, 对应畛域事件或者说命令。
通用语言贯通 DDD 的整个设计过程。作为我的项目团队沟通和协商造成的对立语言，基于它，你就可能开发出可读性更好的代码，将业务需要精确转化为代码设计。
在事件风暴的过程中，领域专家会和设计、开发人员一起建设畛域模型，在领域建模的
过程中会造成通用的业务术语和用户故事。事件风暴也是一个我的项目团队对立语言的过
程。
通过用户故事分析会造成一个个的畛域对象，这些畛域对象对应畛域模型的业务对象，
每一个业务对象和畛域对象都有通用的名词术语，并且一一映射。
微服务代码模型来源于畛域模型，每个代码模型的代码对象跟畛域对象一一对应。
设计过程中咱们能够用一些表格，来记录事件风暴和微服务设计过程中产生的畛域对象及其属性。比方，畛域对象在 DDD 分层架构中的地位、属性、依赖关系以及与代码模型对象的映射关系等。上面是一个微服务设计实例的局部数据，表格中的这些名词术语就是我的项目团队在事件风暴过程中达成统一、可用于团队外部交换的通用语言。在这个表格外面咱们能够看到，DDD 剖析过程中所有的畛域对象以及它们的属性都被记录下来了，除了 DDD 的畛域对象，咱们还记录了在微服务设计过程中畛域对象所对应的代码对象，并将它们一一映射。
DDD 剖析和设计过程中的每一个环节都须要保障限界上下文内术语的对立，在代码模型设计的时侯就要建设畛域对象和代码对象的一一映射，从而保障业务模型和代码模型的统一，实现业务语言与代码语言的对立。
如果做到了这一点，也就是建设了畛域对象和代码对象的映射关系，那就能够领导软件开发人员准确无误地依照设计文档实现微服务开发了。即便是不相熟代码的业务人员，也能够很快找到代码的地位。
什么是限界上下文
刚刚有聊到通用语言, 而确定通用语言适用范围, 精确来说, 确定畛域范畴的就是限界上下文边界, 限界上下文边界英文名 bounded context, 如果间接翻译成上下文边界就更容易了解, 次要目标是为了防止同样的概念在不同畛域产生不同语义或歧义, DDD 在策略上提出 ” 限界上下文 ” 这个概念, 用来确定语义所在的畛域边界。
咱们能够将限界上下文拆解成两个词语: 限界和上下文。限界就是畛域的边界, 而上下文就是语义环境, 通过限界上下文让所有交换的人晓得咱们聊的是在同一个畛域边界内的事件, 合起来就是用来封装通用语言和畛域对象，提供上下文环境，保障在畛域之内的一些术语、业务相干对象等（通用语言）有一个确切的含意，没有二义性。这个边界定义了模型的适用范围，使团队所有成员可能明确地晓得什么应该在模型中实现，什么不应该在模型中实现。
为什么要无限界上下文这个概念
都说中文这门语言十分丰盛，在不同的时空和背景下，同样的一句话会有不同的涵义。有一个例子你应该据说过。在一个明媚的晚上，孩子起床问妈妈：“明天应该穿几件衣服呀？”妈妈答复：“能穿多少就穿多少！”
那到底是穿多还是穿少呢？
如果没有具体的语义环境，还真不太好了解。然而，如果你曾经晓得了这句话的语义环境，比方是寒冬腊月或者是炎炎夏日，那了解这句话的涵义就会很容易了。所以语言离不开它的语义环境。而业务的通用语言就有它的业务边界，咱们不大可能用一个简略的术语没有歧义地去形容一个简单的业务畛域。限界上下文就是用来细分畛域，从而定义通用语言所在的边界。当初咱们用一个保险畛域的例子来阐明下术语的边界。
保险业务畛域有投保单、核保、财务、回访、顾全等保险术语，它们别离利用于保险的不同业务流程。
客户投保时，业务人员记录投保信息，零碎对应有投保单实体对象。
缴费实现后，业务人员将投保单转为保单，零碎对应有保单实体对象，保单实体与投保
单实体关联。
如客户须要批改保单信息，保单变为批单，有顾全零碎对应有批单实体对象，批单实体与保单
实体关联。
如果客户产生理赔，生成赔案，零碎对应有报案实体对象，报案实体对象与保单或者批单实体关联。投保单、保单、批单、赔案等，这些术语尽管都跟保单无关，但不能将保单这个术语作用在保险全业务畛域。因为术语有它的边界，超出了边界了解上就会呈现问题。
正如电商畛域的商品一样，商品在不同的阶段有不同的术语，在销售阶段是商品，而在运输阶段则变成了货物。同样的一个货色，因为业务畛域的不同，赋予了这些术语不同的涵义和职责边界，这个边界就可能会成为将来微服务设计的边界。看到这，我想你应该十分分明了，畛域边界就是通过限界上下文来定义的。
限界上下文在微服务设计中作用以及意义是什么
接下来，咱们对这个概念做进一步的延长。看看限界上下文和微服务具体存在怎么的关系。我想你买过保险吧，或者听过吧。保险承保的流程蕴含了投保、缴费、出单等几个次要流程。如果出险了还会有报案、查勘、定损、理算等理赔流程。
首先，畛域能够拆分为多个子畛域。一个畛域相当于一个问题域，畛域拆分为子域的过程就是大问题拆分为小问题的过程。在这个图外面保险畛域被拆分为：投保、领取、保单治理和理赔四个子域。
子域还可依据须要进一步拆分为子子域，比方，领取子域可持续拆分为收款和付款子子域。拆到肯定水平后，有些子子域的畛域边界就可能变成限界上下文的边界了。子域可能会蕴含多个限界上下文，如理赔子域就包含报案、查勘和定损等多个限界上下文（限界上下文与理赔的子子域畛域边界重合）。也有可能子域自身的边界就是限界上下文边界，如投保子域。
每个畛域模型都有它对应的限界上下文，团队在限界上下文内用通用语言交换。畛域内所有限界上下文的畛域模型形成整个畛域的畛域模型。实践下限界上下文就是微服务的边界。咱们将限界上下文内的畛域模型映射到微服务，就实现了从问题域到软件的解决方案。
能够说，限界上下文是微服务设计和拆分的次要根据。在畛域模型中，如果不思考技术异构、团队沟通等其它内部因素，一个限界上下文实践上就能够设计为一个微服务。不过，这里还是要提醒一下：除了实践，微服务的拆分还是有很多限度因素的，在设计中不宜适度拆分。那这个度怎么把握好呢？无关微服务设计和具体的拆分办法，我会在实战篇中具体解说。
总结
通用语言确定了我的项目团队外部交换的对立语言，而这个语言所在的语义环境则是由限界上下文来限定的，以确保语义的唯一性。而领域专家、架构师和开发人员的次要工作就是通过事件风暴来划分限界上下文。限界上下文确定了微服务的设计和拆分方向，是微服务设计和拆分的次要根据。如果不思考技术异构、团队沟通等其它内部因素，一个限界上下文实践上就能够设计为一个微服务。能够说，限界上下文在微服务设计中具备很重要的意义，如果限界上下文的方向偏离，那微服务的设计后果也就可想而知了。因而，咱们只有了解了限界上下文的真正涵义以及它在微服务设计中的作用，能力真正施展 DDD 的价值，这是根底也是前提。
