聊聊有界上下文
在这篇文章中，我将分享我对有界上下文的看法。有界上下文是什么意思？为什么需要有界上下文？
有界上下文和微服务之间的联系
我会尽量说地简单易懂，所以本文针对的读者是那些在开发微服务时听到术语“有界上下文”但很难理解有界上下文概念的读者。
在深入探讨有关DDD（领域驱动设计）方面的有界上下文之前，我们先来了解一下它在现实世界中的意义。我们知道人类是最聪明的物种，并创造了不同的国家来统治。但问题是，他们为什么要创建不同的国家，有逻辑的边界?两国之间的边界是怎样划定的?在人类文明出现之前，地球上只有陆地，没有国家概念。
我想到了令人信服的答案:为了将行政、文化、法律和经济分开，每个国家都将自己的人民从其他国家中抽象出来，而创造一个统一的文化和语言是可能的任务，就像在古代，不同的部落有自己的语言和文化一样。
在同一个国家，每个公民都遵循一些预定义的规则、语言和风格。他们懂得共同的语言、法律、货币和风格，所以我可以说，在一个国家里，公民之间是同步的，那个国家有一个统一的文化，每个公民都遵循和理解。
在编程中，我们以相同的方式应用有界上下文—在域/问题空间中将不同的模型/子域彼此分离。在领域驱动的设计中，策略设计部分，我们引入了有界上下文，所以在特定的上下文中，模型有一定的含义，就像某个语言和货币具有特定含义的国家。在另一个国家，这种货币和语言是无法理解的，因为它们没有意义，也没有不同的含义。在英语中，“傻瓜”一词的意思是“愚蠢”，但在孟加拉语中，它的意思是“花!”
如果我们认为一个国家像一个有界的上下文和语言/货币作为上下文中的模型，我们可以很容易地将模型的概念映射到特定的有限背景下。该模型对于一个有界的上下文有意义，但是对于另一个有界上下文，相同的模型没有意义（或不同的含义）。在有界环境中，我们创建了一个逻辑边界，模型和商业术语具有一定的含义，有界上下文将模型与外部世界分开/隐藏; 所有的沟通都应该通过API完成。很明显，在有限的背景下，模型和业务逻辑保持一定的规律并保持自己的持久性存储，而这些存储不能直接被其他有界上下文访问。
有界上下文通信
任何设计都有两个公共部分:数据模型的抽象和与系统其他部分的通信。使用有界上下文，我们分离数据模型，抽象业务中的共性。但是一个有界的上下文如何与其他的上下文通信呢?
在这里，上下文映射的概念出现了。使用上下文映射，我们可以发现一个上下文是如何依赖于其他有界上下文的，比如两个上下文是否具有很强的依赖性，或者当一个域向另一个域(conformist)发送确认消息或使用共享内核/共享模型。我稍后将在另一篇文章中讨论上下文映射，但目前，上下文映射是用于在有界上下文之间进行通信的。
这一点上，我相信您已经了解了有界上下文是什么，但是如果您仍然对它如何与体系结构结合有疑问，请参阅下一段。
假设我们必须设计一个在线学生管理系统，学生可以在该系统上注册到该网站，选择课程并支付课程费用，并且他将被标记为一批; 教师和学生会收到有关批次开始日期和时间间隔的通知。
作为架构师，您必须识别与此业务逻辑相关的不同域的有界上下文。如果我们根据相关的功能划分业务逻辑，我们可以找到四个基本功能:
- 注册过程：负责学生的注册。
- 支付系统：将处理课程费用并发布在线支付状态。
- 批次计划：在确认付款后，此功能会检查教师可用性和批次可用性，并根据此创建批次并分配候选人或更新现有批次与候选人。
- 通知系统：它会通知老师和学生关于时间和时间间隔的信息。
所以，有四个有界上下文：注册，付款，调度和通知。
现在，让我们深入了解每个模块如何表示教师，学生和课程模型。
注册过程
它只需要学生信息; 它需要它的人口统计信息，如姓名，年龄，性别，地址以及学生选择哪门课程。在这种情况下，教师是没有意义的。
该支付系统把学生作为支付系统的候选人。只有学生/考生的财务信息是必需的，如帐号，并根据从给定帐户中扣除的课程费用，因此学生的观点完全不同。支付服务所需的信息与注册完全不同，尽管支付系统可能需要少量信息，比如学生的姓名和地址。
“老师”一词在这里无效。在支付系统中，教师被视为教员，，他们可以是永久性的，也可以是承包人，这取决于支付系统为支付计算所选择的教员类型——按小时计算或按平均值来计算。
对于批处理调度系统，它只需要教师和学生最少的信息，例如姓名，地址等，但是它需要在课程和课程下的课程和批次的详细信息。
对于通知系统，我们只需要教师和学生的姓名和电子邮件地址或电话号码，而不需要其他任何东西，它需要学生管理系统的名称和课程详情。在这里，学生管理网站充当发件人和老师，学生被称为收件人。
到目前为止，我们已经看到了相同的域对象：教师，学生和课程在不同的上下文中具有不同的含义和用例。这就是有界上下文的美;对于基于不同上下文的同一域对象，我们有多个规范模型，因此开发人员、企业和用户在讨论上下文时总是在同一页面上。无处不在的语言的概念在这里交织在一起，使用无处不在的语言DDD来创建一个统一的系统，在这个系统中，每个参与者都能根据上下文理解语言。
现在，常见问题是为什么有界上下文术语在微服务中如此流行？
为了回答这个问题，我们首先要理解DDD不仅适用于单片机，也适用于微服务，但是对于单片机，它更加模糊，更像是一种逻辑隔离，因此只有优秀的开发人员才能看到它。最主要的原因是，在一个庞然大物中，我们有一个单一的巨大的代码库。我们可以基于DDD将它分解为多个模块，并在一个模块与另一个模块对话时创建ACL/Translator，但是它仍然需要其他作为依赖jar的模块来调用它的方法。
另一点:由于这是一个单一的代码库，并且有多个程序员在使用它，一些不太熟练的程序员可能会污染边界或域对象。架构师不能基于有界上下文创建物理边界，但在微服务体系结构中，这是固有的，正如微服务所说，我们可以创建具有自己的代码库和通过API或消息相互通信的服务的小型服务，而不是大型代码库。业务域将业务逻辑分解为多个有界上下文，每个有界上下文都是一个单独的代码库，并通过上下文映射进行通信。
要设计上下文映射，您必须仔细设计API; ;您可以使用端口和Hub体系结构，这样您的代码在有界上下文下就不会与外部世界通信，也不会受到污染。微服务提供了这种有界上下文的强隔离。在微服务的上下文中，有界上下文更加可见和容易理解。
结论
有限上下文是您尝试打破大型业务逻辑时的基本需求。它可以帮助您了解系统的不同部分如何以不同的术语以不同的方式使用域对象。有界上下文只是基于功能来正确组织业务逻辑的一种视图，但为了使业务逻辑正常工作，需要有界上下文之间的通信，并且使用上下文映射来实现这一点。在我的下一篇文章中，我将讨论上下文映射。
原文作者：Shamik Mitra
腾讯云开发者
