Domain driven design 领域驱动设计如何连接两个上下文？

如何将一个有界上下文与另一个有界上下文连接起来

例如，我有一个购物车上下文和产品上下文，当我首先将一个产品添加到购物车时，我想检查该产品是否存在，所以我的问题是如何在一个整体项目中连接上下文？

---

免责声明
我知道，在微服务体系结构中，您可以请求特定的API端点来恢复所需的确切对象，并将其映射到值对象。但是在一块巨石上该怎么办呢？创建一个桥接类或创建一个数据库存储库，它将从数据库的某个表中检索值对象？

我期待着您的想法，谢谢您的帮助。

至少有两种不同的方法来管理它

上下文间的数据克隆 在这个解决方案中，您为每个上下文使用多个类似的表，其中数据在每个上下文之间部分复制

因此，为了支持您的请求，您必须在用于购物车的上下文中维护产品数据的副本。 要支持这一点，您可以使用：

使用事件处理程序，每次产品上下文中发生更改时，您都会更新购物车上下文

将信息从一个上下文克隆到另一个上下文的定时作业

两者的混合

其他解决方案

无论如何，无论您选择什么，最重要的是您必须接受最终一致性的概念：您总是使用过时的数据（可能只有几秒钟，但无论如何都是过时的），因此您必须管理由此可能产生的问题。例如，如果购物车上下文中的产品包含不再在仓库中的项目，您会怎么做

您可以（必须…）在每个上下文的基础结构层中实现此支持代码，因此您让所有其他层都不知道它们管理的数据发生了什么。最终，这个解决方案类似于拥有一堆微服务，只是所有东西都构建在一个大项目中

注意：这将是一个纯粹的解决方案，每个有界上下文彼此分离，即使它们都是在单个项目中一起构建的

在多个上下文中重用持久性对象（db表） 在写任何东西之前，我就开始着手：这个解决方案是可能的，但前提是你真的能很好地控制项目的各个方面。有些人会尖叫这是一种反常，另一些人会说在现实世界中，你总是要接受妥协

在这篇序言中，我解释了我的意思：不是在每个使用数据的上下文中都有几个（几乎）表的克隆，而是（可能有很多）代码来支持这一点，而是在多个上下文中直接使用原始表。因此，每当您在购物车上下文中需要产品时，尽管您仍然通过来自该上下文（购物车上下文）的产品存储库的实现来访问它，但实际上您总是从同一个表中获取数据

这有其自身的缺点：可能是上下文需要额外的数据，因此表应该用额外的字段进行扩展（有人会说是被污染的）；表中的每个更改都可能需要检查使用它的代码，因为表是共享的

但是，为了管理克隆，需要编写大量额外的代码。而且，我的观点，在一个受控的环境中，与第一个解决方案所需的额外工作相比，使用一个整体式项目，并将代码构建在一起，是一个巨大的优势。此外，当访问表的代码经过深入测试（无测试，无增益）时，一些问题也更易于管理

---

---

注意（个人体验）：我使用第二种解决方案。我们有一个巨大的整体，有许多表，这些表的数据在多个上下文之间共享。克隆每个上下文的数据的过程是不可行的：仅此过程就花费了太多时间，而没有考虑所有的回退情况。共享表的速度要快得多，让我们可以开发良好的分割边界上下文。我不使用JPA（JavaORM），所以我控制加载域实体的SQL代码。持久性访问的所有内容都经过了测试，因此每当发生变化时，我都会立即得到报告。

我对第二个解决方案有一个问题，您是在购物车上下文中创建产品实体的克隆还是通过存储库加载的不可变值对象？我创建了一个全新的实体，当绑定上下文需要存储库来管理此信息时。否则，我将创建一个值对象，以便将克隆的数据直接加载到另一个实体中。这意味着查询在某个地方连接了原始表的数据。无论如何，在任何情况下，我都不会使用相同的类，或者从它们继承的类。我使用的总是全新的，完全符合实际上下文的需要，避免了来自其他上下文的任何依赖。