DDD :一个聚合根，多个持久数据源

Question

在指南/eBook：.NET微服务:用于装载.NET应用程序的体系结构 (与eShopOnContainers相关)一章“设计基础结构持久层”(第213页)中，通常解释聚合根如何对持久数据源执行CUD操作。

其中提到了两个重要的起点：

1. 根据持久性无知和基础设施无知原则(第218页)，聚合不了解持久化和基础结构的方法。聚合是由业务而不是由基础结构决定的。
2. 每个聚合根只应定义一个存储库，以保持聚合内的对象之间的事务一致性(第213页)

不幸的是，在提到的所有其他示例中，聚合根和属于它的所有底层对象都在同一个持久数据源中。

然后，模式如下：

1. 创建了一个包含该聚合的存储库。
2. 在这个存储库中，在创建过程中注入了一个工作单元。这个工作单元包含诸如SaveChangesAsync、SaveEntitiesAsync、Update等方法。
3. 在命令中，工作单元管理到这一个数据源(如数据库或类似数据源)的事务。

我想扩展这种模式，根据底层对象类型，聚合可以在2个或更多物理数据源上写入其数据。

从起点1开始，完全可以根据基础对象的类型将根聚合及其基础对象更新为不同的数据源。提到的例子有:数据库和XML文件、数据库和NOSQL‘数据库’、数据库和服务、数据库和IoT设备。因为聚合必须对持久化和基础结构的方法一无所知，所以在我看来，没有必要争论聚合的设计。我认为书中没有提到聚合根应该在一个数据源中持久存在。

同时，起点2似乎也是完全合理的。因为聚合根目录中的完整对象集是编辑的，整个包的成功持久性是从一个存储库协调的，并且(最好)是从一个工作单元协调的。

问题是:如何处理领域驱动的设计，如果在聚合--取决于底层对象的类型--它是通过不同的数据源被水化的？我应该使用一个自定义的工作单元，并在这个UoW中决定写到哪里吗？

我知道下一个问题，但在研究了代码之后，我认为它只处理处理不同数据源的存储库的继承，但在当时仍然为一个数据源服务，这不是我想要的。

Answer 1

我想扩展这种模式，根据底层对象类型，聚合可以在2个或更多物理数据源上写入其数据。

你为什么要故意这么做？

在大多数情况下，选择持久性实现是为了服务域，而不是反过来。因此，愉快路径通常涉及选择一个持久性解决方案，该解决方案可以记录整个聚合的状态，并将整个事件存储在单个事务中。

因此，如果你发现自己试图在两个不同的地方存储一个聚合，你应该仔细地看看为什么。

一个常见的答案是，您希望能够有效地查询聚合状态。cqrs在这里是一个常见的解决方案--与其将聚合保存在两个不同的数据存储中，不如将其保存到一个数据存储库中，然后将其复制到另一个数据存储库中。查询可以非常有效地针对副本运行(当然，在对聚合的更改与在查询结果中反映该更改之间还有一些额外的延迟)。

另一个常见的答案是，您确实有两个相互引用的聚合。在不同的地方存储两个聚合没有什么错。通过在代码中明确区分这两种方法，您可能会得到更好的服务。

• 丹·普里切特
• 吉米·博加德

如何处理领域驱动的设计，如果在聚合-取决于基础对象的类型-它是在不同的数据源水化？

很糟糕就像其他人一样。