如何清楚定义边界上下文的边界

经过一个月左右的阅读和研究DDD，我决定开始自己的项目，并使用这些有限的上下文创建DDD。

• 客户群
• 产品展示
• 命令
• 开票

每个有界上下文都有其余的API作为表示层，域层，持久层。

到目前为止，代码运行顺利，但是来自一个单一的世界，我仍在尝试找出以下内容：

• 当我想创建一个新客户时，发出新发票，创建我想要的新订单，例如访问国家列表。我要：

a）在每个卑诗省创建一个国家列表

b）创建一个国家BC-> API并使用它来获取可用国家的列表

c）使用第三方API并通过每个BC中的反腐败层提取数据

• 当使用反腐败层或适配器层与第三方API集成时，我的域模型中必须包含哪些数据？例如，如果我想将zendesk API与Client BC集成在一起。我是否仅需要我域中的ticketID，还是必须从Zendesk中提取要在Client BC中访问和使用的所有数据？

如果我的MVC应用程序实际上是从API（我的受限上下文的表示层）获取数据的，那么我很难清楚地定义每个BC的边界。这是否意味着经过适当设计的BC可以为单个MVC控制器提供服务，而无需使用其他API？

如果您不同的边界环境对一个国家的含义/目的的理解不同，那么您就需要在每个模型中适当地建模一个国家。但是，如果仅说ISO代码和名称的参考数据，那么我认为将其存储在任何方便的地方并使其对所有相关方都可用是相当公平和标准的。例如：数据库，配置文件，Web服务等。

我也想看一下您的模型。根据公司的结构，您列出的作品很可能是一个“受限制的上下文”中的“实体”。BC通常最终会围绕不同的区域/部门/团队进行定义，因为这通常是“无所不在的语言”之间的自然界限。因此，举例来说，我希望BC不会像Sales / Products / Orders那样与Sales / Manufacturing / Warehousing相似。

在这些BC中，您不必关注名词。您专注于用例，并创建可以满足用例的名词模型。“聚合根”上的方法执行用例并对相关模型进行适当的更改。

...所有模型都是错误的，但有些是有用的。

还请记住，每个BC可能使用完全不同的系统或体系结构。给定的BC可能根本不适合使用“ DDD软件组件”，而大多数BC根本不值得。DDD与规定性软件组件无关，而与软件设计过程有关。重点是着重于了解公司的受限上下文，映射每个上下文的通用语言，并使用它们的通用语言对该上下文的代码进行建模。这样，当您与利益相关者互动并参考代码时，对他们来说听起来就像您在使用他们理解的商业术语说话一样。并且认识到同一单词在不同的BC中具有不同的含义。

DDD带来了特定的模式（例如，存储库，特定的分层等），这是达到目的的手段。但是，即使在DDD中，也不能保证这些模式是每种情况下的最佳模式。就像DDD并不是每个项目的“答案”一样。您只需要执行分析所建议的最实际的操作即可。

从您的问题中，我认为您误解了有限的上下文。您可能需要重读蓝皮书的第14章。

尝试一般性地回答-在两个不同的有界上下文之间共享概念时必须小心。毕竟，存在边界的部分原因是无处不在的语言发生了变化。假设在两种情况下都可以使用实体的相同数据（和相同表示形式）是幼稚的-可能是正确的，也可能是错误的，但是对于我们这些人来说，没有访问的好方法给您的领域专家判断。

例如，在客户域中，“国家”可能与居住地或公民身份有关。在计费中，它可能与货币汇率有关。在某些领域中，您可能需要担心关税等问题。

您需要提出的第二个问题是哪个模型是“共享”数据的记录簿。对于“国家”，正确的答案可能是它们都不是！地缘政治拓扑不受模型控制。

当一个国家被一个外国大国占领时，在您的域模型中应该发生什么？

记住; 我们很多人习惯于思考数据结构；一个数据和另一个数据之间的关系是什么？当您考虑报表并尝试确保解决方案已收集了所有需要的数据时，这很棒。但是领域模型不仅与结构有关，而且与变化有关。您还需要注意这一部分，并确保您充分理解数据如何约束更改（以及这些约束从一个有界上下文到下一个约束上下文如何变化）。

您提到的概念（客户，产品，订单，开票）通常在单个域模型中表示，因此在有界上下文中表示。我建议您错误地理解这些概念。

我对此主题的看法是使用业务能力映射或其他类似技术（例如价值链分析）来定义有界上下文。它归结为以下步骤：

1. 定义系统的更高级别的职责或业务能力。我认为最好的方法是联想您的企业为获得业务价值所经历的步骤。您想到的逻辑边界是您的业务服务，或者，如果您愿意，则是有限的上下文。
2. 深入研究每个服务。
3. 在前两点中确定服务之间的通信。

因此，最初的重点是您的业务运作方式。

几个实用建议：

1. 如果您的上下文/服务/等之一需要其他上下文的数据，则很可能您的界限是错误的。
2. 高度期望的上下文通信方式是基于事件的。这是可伸缩性和可靠性的关键。如果您需要同步通信，则很可能边界再次错误。除此之外，同步通信将杀死您的系统。
3. 您的域最终的一致性比您想象的要好。就像其他人一样。不要试图使所有内容保持100％一致。这没有实际意义。
4. 上下文不需要进行协调。他们是独立的。像人类一样。

通过这种方法，您最终将获得高度自治，可维护和可靠的服务。您可能需要查看定义上下文边界的示例。