我认为范围有限的上下文
在本文中，我将分享有关“边界上下文”的观点。 我将尝试回答一些问题，例如这意味着什么以及为什么需要它。 我们还将尝试检查Bounded上下文和微服务之间的联系。
我将尝试使其尽可能简单。 本文针对的对象是那些在开发微服务时会听到“绑定上下文”一词的读者，但他们正努力仅了解绑定上下文概念。 在根据DDD（域驱动设计）深入研究“边界上下文”之前，让我们了解一下它在现实世界中的含义。
我们知道人类是最聪明的物种，人类为这一裁决创造了不同的国家。 但是问题是为什么他们创建了不同的国家或逻辑边界？ 两国在什么基础上划清界限？ 例如，在人类文明之前，地球上只有土地，没有任何国家的概念。
我想到的一个令人信服的答案是将行政管理，文化，法律，经济学分开，这样，每个国家都可以从其他国家中抽离自己的人民，除非创建统一文化是不可能的任务。 在远古时代，不同的部落都有自己的语言和文化。
在同一国家/地区，有一些预定义的规则，每个公民都应遵循该规则，例如语言，风格等。例如，他们了解通用语言，了解法律，货币和风格，因此我们可以说公民彼此之间是同步的在一个国家中，那个特定国家拥有一种统一的文化，每个公民都应该遵循和理解！
在编程中，我们以相同的方式应用Bounded上下文。 为了在领域/问题空间或在领域驱动的设计–战略设计部分中将不同的模型/子域彼此分开，我们引入了有界上下文，以便在某种上下文中模型具有某种意义，例如我们提到的国家/地区在此之前，对于特定国家/地区特定语言，货币具有特定含义。 但是在另一个国家中，货币或语言是无法理解的，因为它对那个国家没有意义或具有不同的意义。 像傻瓜这个词。 例如在英语中它意味着愚蠢，而在孟加拉语中它意味着花！
因此，如果我们将“国家/地区”视为有界上下文，并将语言/货币视为该上下文中的模型，则可以轻松地在特定的有界上下文中映射域模型的概念。 该模型对于有界上下文具有某些含义，但是同一模型对于另一个有界上下文则没有含义/不同的含义。 因此，通过有界上下文，我们创建了一个逻辑边界，其中模型和业务术语具有一定的含义，有界上下文将模型与外部世界分离/隐藏。 所有通信均应通过API完成。 因此，很明显，在有限的上下文中，模型和业务逻辑会维护一定的规则并维护自己的持久性存储，而其他有限的上下文则无法直接访问。
有界上下文沟通
每个设计都有两个共同的部分，即数据模型的抽象以及与系统其他部分的通信。 通过有限的上下文，我们以简单的术语将数据模型分离，从而抽象出业务中的共性。 但是，让我们看看一个有限的上下文如何与其他上下文进行通信。
在这里，我们将讨论上下文映射的概念。 使用上下文映射，我们可以发现一个上下文如何依赖于其他有界上下文，例如两个上下文具有很强的依赖性，或者一个域向另一域（Conformist）发送确认消息，或者可以使用共享的内核/共享模型。 我将在另一篇文章中讨论上下文映射，但是现在，想象一下上下文映射用于在绑定上下文之间进行清晰的通信。
在这一点上，我相信我们已经涵盖了什么是有界上下文的基本概念，但是如果您仍然对其在建筑中的适用性仍有疑问，可以跳到下一段。
假设我们必须设计一个在线学生管理系统，学生可以在该系统上注册并选择相应的课程，并支付课程费用，然后将他们标记为一个批次，这样一来，教师和学生都会收到有关该批次的通知。开始日期和时间段。
作为架构师，您必须标识与此业务逻辑相关的不同域的有限上下文。 如果我们根据相关功能划分业务逻辑，我们可以找到四个基本功能。
- 注册过程 ：负责学生的注册。
- 付款系统 ：将处理课程费用并发布在线付款状态。
- 批次计划 ：确认付款后，此功能将检查教师的可用性，批次可用性，并基于此功能创建一个批次并分配候选者，或使用该候选者更新现有批次。
- 通知系统 ：它将通知教师和学生有关时间和时段信息。
因此，有4个有界上下文：注册，付款，计划程序和通知。 现在，让我们深入研究每个模块如何表示教师和学生以及课程模型。
注册过程：仅需要学生信息，还需要其人口统计信息，例如姓名，年龄，性别，地址以及学生选择的课程。 在这种情况下，老师是没有意思的。
付款系统：它将学生视为候选人。 在付款系统中，仅需要学生/候选人财务信息，例如帐号，并根据课程费用从指定的账户中扣除金额。 因此，从学生的角度来看，支付服务所需的信息与注册完全不同，尽管支付系统可能需要几条信息，例如该学生的姓名，地址，但这些仅仅是基本信息。
术语“教师”在这里无效。 在支付系统中，教师被视为教师，根据教师类型的支付系统，它可以是永久性的，也可以是承包商。 您可以选择按小时还是按年计算付款方式。
批量计划：如果使用批量计划系统，则需要老师和学生提供最少的信息，例如姓名，地址等。但是它需要课程，课程下的批次等详细信息。
通知系统 ：对于通知系统，我们只需要教师和学生的电子邮件地址或电话号码和姓名。 不需要进一步的信息。 它还需要学生管理系统的名称和课程详细信息。 在这里，学生管理站点充当发件人，而老师和学生则代表收信人。
到现在为止，我们已经看到相同的领域对象（如教师，学生，课程）具有不同的上下文含义和用例。 这就是边界环境之美。 对于基于不同上下文的同一域对象，我们还具有多个规范模型，以便开发人员，业务用户在谈论上下文时始终位于同一页面中。 在这里编织了无处不在的语言的概念。 使用无处不在的语言DDD，创建了一个统一的系统，每个参与者都可以基于该上下文理解该语言。
现在，常见的问题是，为什么有界上下文术语在微服务中如此流行？
首先要回答这个问题，我们必须了解DDD适用于Monolith和Microservice。 但是在Monolith的情况下，它比较模糊，而且在逻辑上更加隔离，因此只有优秀的开发人员才能看到它。 主要原因是，在整体中，我们只有一个巨型代码库，当一个模块与另一个模块通信时，我们可能会基于DDD创建者ACL / Translator破坏它的多模块，但仍然需要其他模块作为依赖的jar来调用其方法。
另一点是，这是一个单一的代码库，并且有多个编码器在其中工作。 因此，一些不太熟练的编码人员会污染边界或领域对象。 在那种情况下，Architecht不能基于“边界上下文”创建物理边界。 但是在微服务中，架构是固有的，因为正如我们所说的，我们可以创建具有自己的代码库并且服务可以通过API或消息传递相互通信的小型服务，而不是大型代码库。 因此，很明显，Business Domain将业务逻辑分解为多个有界上下文，并且每个有界上下文将是一个单独的代码库，可以通过上下文映射进行通信。
要设计上下文映射，您必须仔细设计API。 您可以使用Port and Hub架构，以使Bounded上下文中的代码不与Outerworld进行通信，因此不会造成污染。 微服务提供了这种有界上下文的强隔离。 在微服务的上下文中，绑定上下文更加可见和易于理解。
结论
当您试图破坏大型业务逻辑时，Bounded Context涵盖了基本需求。 它可以帮助您了解系统的不同部分如何以不同的方式以不同的术语使用域对象。 绑定的上下文只是根据功能正确组织业务逻辑的一种视图。 但是，为了使业务逻辑起作用，需要在有界上下文之间进行通信，并且出于相同的原因，它也使用了上下文映射。 在下一篇文章中，我将讨论上下文映射。
翻译自: https://www.javacodegeeks.com/2018/05/bounded-context-in-my-view.html