存储库模式:每个聚合的存储库还是每个底层数据存储的存储库?

发布于 2024-10-21 13:12:23 字数 537 浏览 2 评论 0原文

它是建议每个聚合有一个存储库。

但是,我有一个情况,可以从 2 个异构数据存储中获取相同的聚合对象。对于后台,该对象是:

  1. 从数据存储A(远程和只读)中获取,
  2. 呈现给用户进行验证
  3. ,导入到数据存储B(本地和读写)
  4. 它可以从数据存储中获取和修改 B

显然(或不是),我不能为此拥有一个唯一的聚合存储库 - 在某些时候我需要知道从哪个数据存储中获取对象。

鉴于域层应该忽略基础设施,我的特殊情况在某种程度上打破了我对存储库模式和 DDD 一般应如何正确实现的理解。

我是不是搞错了什么?

It is recommended to have one repository per aggregate.

However, I have a case where the same aggregate object can be fetched from 2 heterogeneous data stores. For the background, that object is:

  1. fetched from data store A (remote & read-only)
  2. presented to the user for validation
  3. on validation, imported into data store B (local & read-write)
  4. it can be fetched from and modified in data store B

Obviously (or not), I can't have a unique aggregate repository for that - at some point I need to know from which data store the object is fetched.

Given that the domain layer should ignore the infrastructure, my particular case breaks somehow my understanding of how the repository pattern and DDD in general should be properly implemented.

Did I get something wrong?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

北渚 2024-10-28 13:12:23

我是不是搞错了什么?

在我看来,你的错误是为相同的数据拥有两个数据存储。

如果这种冗余确实有充分的理由,那么这两个聚合必须在某种程度上有所不同,这可能证明将它们视为单独的聚合并拥有两个存储库是合理的。

如果您想将它们视为单个聚合,则单个存储库应该知道如何消除歧义并处理正确的数据存储,但将数据存储的知识封装到远离域模型的地方。

编辑:

在评论中解释的情况下,一个数据存储是只读的,另一个是本地可修改的副本,实际上拥有两个数据存储是被迫的。您的存储库需要了解这两个数据存储,并且仅当在本地找不到某些内容时才使用远程只读存储。从远程检索某些内容后,应立即将其保存到本地,然后使用本地副本。

这个逻辑有点像缓存代理,但不完全是这样,因为远程是只读的,而本地是读写的。它可能包含足够的逻辑,可以提取到存储库使用的服务,但不应暴露给域。

这种情况也存在一些风险,您需要考虑。一旦您在本地保存了某些内容,您就会拥有相同数据的两个版本,这将不同步。如果在您更改本地设备后,具有远程写入权限的人更改了它,您该怎么办?

Did I get something wrong?

Seems to me what you got wrong is having two data stores for the same data.

If indeed there's a good reason for this redundancy, the two aggregates must be different in some way, and that might justify considering them as separate aggregates and having two repositories.

If you want to treat them as a single aggregate, a single repository should know how to disambiguate and deal with the correct datastore, but encapsulate that knowledge of datastores away from your domain model.

EDIT:

In the situation as explained in comments, where one datastore is read-only and the other a local modifiable copy, having two datastores is in fact forced on you. Your repository needs to know about both datastores and use the remote read-only store only if it does not find something locally. Immediately upon retrieving something from the remote, it should save it to the local and thereafter use the local copy.

This logic is sort of a caching proxy, but not exactly, as the remote is read-only and the local is read-write. It might contain enough logic to be extracted to a service used by the repository, but shouldn't be exposed to the domain.

This situation also has some risks that you need to think about. Once you've saved something locally, you have two versions of the same data, which will get out of synch. What do you do if someone with write access on the remote changes it after you've changed your local?

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文