Domain driven design DDD中聚合的不同持久性存储库

我有一个包含根实体（文档）和VO（文档）的聚合。文档与文件（PDF、图像、office文档等）关联，因此我必须将聚合保存在数据库中，并将文件保存在ftp服务器中（文件无法保存在数据库中，因为空间文件太大）。 MyDB repository类使用FindXXX、AddDocument、removedDocument等方法实现一个接口。如何实现ftp持久性？我的数据库存储库是否应连接到AddDocument和RemoveDocument中的ftp设置程序？或者我应该创建一个实现该接口的ftp存储库类。如果是这样，像FindXXX这样的方法就没有意义了。 据我所知，每个聚合只有一个接口存储库，表示如何持久化。它可以有多种“持久化模式”（在数据库、ftp、文件等中），但接口应该相同

据我所知，每个聚合只有一个接口存储库，表示如何持久化

这基本上是正确的；人们通常认为整个聚合将存储在一个地方。当您将聚合的状态分布到多个存储单元时，需要非常小心地注意故障模式

要考虑的是单独存储的文档是否是聚合的一部分，或者是集合所引用的内容。

如果它们被聚合引用，则将它们视为对其他聚合的任何其他引用。文档聚合存储文档的标识符/引用/提示，并在需要时利用域服务访问文档

如果它们是聚合的一部分，那么通常的答案是“存储库”将是复杂基础设施前面的一个门面，它掩盖了文档和文档分开存储的事实

---

换句话说，基础设施层将尝试协调加载和存储操作，系统的其余部分不需要知道细节。

延迟响应。但是，简单地说，您应该有两种服务。在我阅读DDD时，存储库通常被视为基础设施服务。在本例中，您有两个：

用于存储和基本检索文档ID、元数据和引用的存储库/接口

用于存储和基本检索数据块的存储库/接口

有时，拥有多个聚合和存储库是有意义的。事实上，有界上下文（）上的一些Vaughn Vernon示例确实包含包含对其他聚合的引用的聚合。我认为你应该做有意义的事，做你觉得合适的事

事实上，如果你在经营一家邮局的募捐中心，你很可能会有一个1。存储从小到大的包裹，以及2。管理每个小到大包裹在中心位置的索引，以便您可以检索它

MyDB repository类使用FindXXX、AddDocument、removedDocument等方法实现一个接口。如何实现ftp持久性？我的数据库存储库是否应连接到AddDocument和RemoveDocument中的ftp设置程序？或者我应该创建一个实现该接口的ftp存储库类

如果您的数据库存储库除了连接到其他一些数据存储之外还连接到FTP，那么您可能在一个领域中投入了太多的逻辑和责任。也就是说，这样做也没什么错

如果是这样，像FindXXX这样的方法就没有意义了。据我所知，每个聚合只有一个接口存储库，表示如何持久化

对于这个特定的问题，大多数DDD从业者会建议您使用单独的视图服务/模型。它可以跨存储库或服务生成具体化/视图DTO

---

从根本上说，测试单个部件和替换底层实现应该很容易。如果有一天您决定从FTP切换（甚至包括支持）到Google云存储/AWS S3，那么可能会涉及更多的工作和测试用例的更改。

Mmm。。有趣的问题。我也不确定。部分原因是它是聚合的一部分，因为文件（文档VO类）是文档实体的一部分。但是，另一方面，当我在存储库中执行FindXXX方法时，我不会加载ftp站点中的所有文档，我只加载db信息。我不确定什么是正确答案。