限界上下文（BC）是什么

翻译自 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