共计 1720 个字符，预计需要花费 5 分钟才能阅读完成。
翻译自 DDD – The Bounded Context Explained, 有整理
你问的限界上下文（BC）是什么？
“特定模型的分隔适用性。限界上下文使团队成员能够清楚地分享对必须一致的内容以及可以独立开发的内容。”
看定义看懂了吗？
BC 是最难解释的 DDD 原则之一，但它可能是最重要的，因为没有 BC 就不能做 DDD。因此，您必须了解如何在实际获取根聚合，聚合，实体和值对象之前识别 BC。
让我们再试一次：上下文意味着具体的责任。限界上下文意味着责任是通过明确的边界来强制执行的
举个例子
过程
约翰，X 公司的开发人员。约翰在 IT 部门工作
丽塔，她是同一家公司的会计师。丽塔在会计部门工作
此时，IT 部门是一个限界上下文，会计部门是另一个限界上下文
IT 部门有责任处理公司中与 IT 相关的所有事务，而会计部门处理与会计相关的所有事务
约翰不会进入丽塔的办公室并修改工资单，而丽塔也不会去约翰的办公室并修改他的代码。
虽然他们可以这么做，但这将是一个丑闻。因为如果他们这样做，他们将超越他们的界限。
如果丽塔在会计软件（内部开发）中发现错误，她会致电 IT 部门处理。她不会启动 Visual Studio 并开始搞乱代码。这既不是她的责任同时她也不需要知道怎么做，即使她知道 VS 是约翰用来编写代码的程序（事实上，VS 在会计师的计算机上将是一个非常奇怪的软件）
同样明智的是，工资单文件或发票在 IT 部门中是没有位置的。
当然，当约翰遇到涉及工资单的问题时，他要求丽塔调查一下。
两者都尊重彼此的界限，并根据自己的责任行事。
但 IT 部门本身分为两组：软件开发组和管理组。第一组实现功能并修复错误。第二组处理服务器。每个组也是有限的上下文。他们有自己的责任和明确的界限。DBA 不编写 C#代码，约翰不会破坏服务器配置。每个人都按照自己的责任行事并在自己的范围内行事。
两者都有非常精确的责任，他们的界限非常明确。
小结
所以，IT 部门是 BC。约翰是其模型的一部分。事实上，所有有意义的东西（开发人员，服务器等）都是 BC 的一部分，它应该在内部保持一致（开发人员应该编写软件而不是询问发票）。这意味着丽塔在 IT 方面没有地位，她不应该处理与 IT 相关的任何事情。丽塔是会计 BC 的一部分。她可能正在访问 IT 办公室，但她只是一个匆匆过客，她对该部门毫无意义，没有人希望她编写代码或充当开发人员。约翰可能喜欢丽塔，并花了一些时间在她的办公室，但这并不能使约翰成为一名会计师。
不同 BC 之间的“合作”
BC 与 BC 的关系
我们可以看到，在一定程度上，BC 是自治的，它们不重叠。此外，如果来自一个 BC（X）的对象转到其他 BC（Y），它并不意味着它现在是后者的一部分，它仅被视为一个对 Y 没有意义的简单对象。所以它们几乎是独立的，那么他们如何一起工作？
不同 BC 之间该如何合作
例子说明
登场新人物 -> 安德鲁 (IT 部门经理)
按照例子来说，当会计部门必须和 IT 部门合作的时候该如何做？
他们通过与合适的人交谈来做到这一点。
当丽塔需要一个新的软件功能时，她可以告诉约翰，但约翰的经理（安德鲁）最终决定是否添加，以及将添加哪些功能。
当你想要新功能甚至修复一些错误时，是需要与安德鲁交流的。安德鲁是 IT 经理，他告诉约翰（或 IT 的其他任何人）下一步该做什么。
丽塔不能忽视安德鲁，因为这是 IT 部门的规则：安德鲁做决定。你必须按照安德鲁想要的方式提出你的想法，否则他们会被拒绝。当要求对 IT 不符合方式且没有意义的时候，要求会自动被拒绝。
安德鲁是 IT BC 的反腐败层，没有什么决定能够跳过他，它适合于 IT 部门的内部组织。
类比到代码
这些例子很简单，但我们的代码呢？我们确实希望我们的 BC 能够解耦，所以 BC1 不应该知道 BC2。好吧，这个想法是一个 BC 不应该知道其他 BC 的内部，这两个可以使用公共对象（DTO）直接将消息传递给另一个或者是专门的适配器，它知道如何与两个 BC 通信。虽然通过域事件（基本上是更高级别使用的观察者模式）的首选方法。
结束语
哇，很长的帖子，但我希望你现在对一个有限的背景有一个非常明确的理解。以下是常见有界上下文的一些示例：应用程序本身，UI 层，域层以及它们的最小 BC：对象，任何对象。
参考
DDD – The Bounded Context Explained
