architecture - 同一事务下的多个存储库

Question

想象一下这样一种情况，应用层打开一个新事务，你想在这个事务下执行 2 个存储库操作。假设我想使用 IUserRepository 添加一个新用户，然后保存在用户域模型状态更改期间生成的所有事件。我在 ApplicationLayer (TransactionScope) 中打开一个新事务，然后执行这 2 个操作。但是如果明天我想将存储库实现更改为 FileBasedRepository 或 HttpCloudRepository。存储库不知道它们在某些事务下运行的事实，还是应该知道？主要问题是关于抽象的。我们都努力编写基于抽象的代码。我看到的是，如果我实现了一个工作单元并使用应用层中的 2 个存储库更新了 2 个聚合(存储库与 MSSql 一起使用)，明天我无法将其中一个存储库实现更改为基于 http 或基于内存。问题是如何编写这样的代码。似乎我必须为事务创建一个抽象并自己为 HttpUnitOfWork 实现回滚。感觉我最初的工作单元与 db 紧密耦合，应该重命名为 DbUnitOfWork。但这又错了，因为没有完全不支持事务的 sql 数据库。

Answer 1

Repositories don't know about the fact that they are running under some transaction, or should they?

这是 Evan 在 Blue Book 中所写的内容。

The REPOSITORY concept is adaptable to many situations. The possibilities of implementation are so diverse that I can only list some concerns to keep in mind.... Leave transaction control to the client. Although the REPOSITORY will insert and delete from the database, it will ordinarily not commit anything.... Transaction management will be simpler if the REPOSITORY keeps its hands off.

说实话，我发现这个概念很难与同一章的其他著作相协调。

For each type of object that needs global access, create ( a REPOSITORY ) that can provide the illusion of an in-memory collection of all objects of that set.

在我通常使用的语言中，内存中的集合通常管理自己的状态。这是否意味着事务控制应该在集合接口(interface)之后，而不是留给客户端？

另外一点是，我们的持久性解决方案变得更加复杂；对于 Evans，域模型只管理对单个数据库的写入，它支持可以跨越多个聚合(即，RDBMS)的事务。但是如果你改变这个假设，那么很多事情就会变得更加复杂。

cqrs在这里提供一些提示。 从存储库中阅读很漂亮；您将实现的所有复杂性隐藏在一些与持久性无关的外观后面。编写可能会比较棘手——如果您的域模型需要支持将多个聚合保存在一起(同一个事务)，那么您的“存储库”接口(interface)应该明确说明。

这些天来，您可能会看到更多的支持，即对聚合的修改应始终在单独的事务中进行。这减轻了存储库协调的一些压力。