问在有界上下文中使用多个数据库

EN

“工作单位”不一定与多个数据库不兼容。它与不同的服务/进程不兼容，其中每个服务都有自己的存储系统。

在一个服务中，一个UoW理论上可以容纳两个或多个不同的数据库上下文，在两个服务上执行一个组合事务，并在另一个数据库的提交操作失败时管理对另一个数据库的手动回滚。然而，这意味着您将同时使用两个数据库并同步使用一个服务，这可以很容易地引入缩放问题。

由于您提到了事务发件箱模式，我认为您所想到的体系结构看起来是不同的:每个数据库都由不同的(微？)控制。服务，这意味着您需要分布式事务。“发件箱”是实现此功能的一种常见方式，它将业务事务分成两个或多个技术事务，每个服务至少有一个。

这样，您就可以使用UoW来

• 收集用于其数据库的一个服务内部的CRUD操作，以及更新依赖服务所需的命令
• 当涉及提交时，应用CRUD操作以及插入到发件箱表中，并将前面提到的命令作为有效负载。

然后，依赖服务将从发件箱中获得由消息中继和消息代理生成的事件，并必须相应地解释有效负载。也许为了解释事件，他们必须自己创建一个UoW，这将取决于总体的复杂性。在最坏的情况下，这里的失败事务需要生成一个事件来再次回滚第一个事务(但这与情况有关，当您的不同数据库在这种程度上相互交织时，您可能会重新考虑将数据拆分到不同DBMS中的选择)。

TLDR；UoW是一个服务的实现细节，当您的数据库处于不同服务的控制之下，并且您的业务事务跨越多个服务时，一个UoW就不足以实现一个业务事务。

除了@DocBrown的答案。

请允许我再“快一点”一点。

如何有一个工作单元来管理两个数据库之间的事务(我认为答案是:不可能)

如果您询问如何将两个数据源的事务链接到一个单独的按酸方向的事务，则答案是分布式事务。坏消息是，实施起来并不容易。至少还不够简单，无法从UoW中完成。

分布式事务也很难实现，因为并非所有数据源都支持这些事务。如果没有，则需要一个自定义实现。自定义实现有两种形式:中间件(例如应用服务器)或自定义事务管理器(例如库)。在这两种情况下，UoW都会请求与这个新的“层”建立新的连接，并将其操作为一个常规DB事务。在幕后，事务管理器/中间件完成所有困难的工作。

如果要实现自定义事务管理器，考虑到事务的短暂性，两阶段提交算法看起来是一个很好的起点。

现在请记住以下几点:不能假设所有数据源都实现ACID事务。希望您的数据库能够打开连接、创建事务、保存(提交)数据或对称地还原更改(rollback)，但是如果其中一个数据库不支持回滚或ACID事务，则必须向事务管理器提供自定义故障转移策略。例如，当不支持回滚时，事务管理器必须执行补偿事务。这些事务也需要事务管理..。正如您可能猜到的，编码不是一件琐碎的事情。