在定义有界上下文时，应该以什么为主要准则？

Question

在定义域的有界上下文时，应该以什么为主要准则：

• 部门(销售/制造/仓储)，其中每个部门都有一个共同的上下文(https://softwareengineering.stackexchange.com/a/316829/226099)
• 工作负载，例如，销售BC可以分解为客户管理，计费，销售代理BCs，以便有较少复杂的领域模型，并能够更容易地扩展

有界上下文的实际范围应该有多窄？是由我们根据域当前和未来的需求来定义BCs，还是在定义BCs时有一个共同的规则要遵循？

Answer 1

有界的上下文应该相对较小，但是足够大，只能捕获孤立业务领域的完全无处不在的语言，而不是更大的

Answer 2

据我理解，有界上下文的主要功能是封装一组用户使用的公共语言。这是一个主要工具，可以在软件抽象中反映已经使用的术语，而不是创建不自然的抽象来满足所有用户。

海事组织划定上下文边界的主要准则是不要过多地考虑这个问题。这一切都是关于已经使用的术语，所以你必须与用户一起工作，倾听他们的语言，询问他们的意思，并在需要的时候(或者仅仅是自然的)画一个界限。

就具体的指导方针而言，我可以想到以下几点：

1. 如果两个实体的名称相同，但含义不同，则两个实体绝对应该用上下文边界分隔，
2. 一组用户已知的一组术语(让我们称之为A)可能应该与其反集(整个域减去A)分开。
3. 保持有限的上下文自给自足(能够自己提供功能)可以将它们移动到不同的进程、(微观)服务，甚至是独立的系统。

在域创建之后，您可以将其与公司的部门(或任何其他部门)进行比较，作为死后分析的一部分。

Answer 3

有界上下文包含域模型。因此，通常情况下，有界上下文表示应用程序或微/服务。

一个大型应用程序(如ERP套件)可能有多个有限制的上下文，表示套件中不同的应用程序，例如CRM、会计、采购、人力资源。

如果修改现有应用程序的部分，通常会将现有的、不变的部分识别为一个有界的上下文，而新的部分则识别为它自己的有界上下文。

有限上下文之间的重叠，即共享模型的一部分，很少被成功地进行，而现在与更现代的服务/微服务体系结构不一致。