gpt4 book ai didi

architecture - 在 DDD 中,域模型实体可以访问其存储库吗?

转载 作者:行者123 更新时间:2023-12-04 02:08:19 30 4
gpt4 key购买 nike

我目前正在使用领域驱动设计 概念设计和实现一个框架。

我正在尝试将 Validation 放在域模型层中。

有时做验证需要访问数据库并查询它,例如:

"querying to check multiple column unique index"

关于这一点以及查询应该写在存储库层类中的事实,结果表明领域实体需要在领域模型层中引用其存储库接口(interface),以便将验证完全放在领域中模型层。

我想知道域实体是否可以访问存储库?

如果不行,那么应该如何处理这种情况?

我的意思是应该将此类验证方法移动到 repositoryApplication Service 层吗?如果是,是否可以将验证方法移动到这些层?

或者由于领域服务可以访问存储库,我们是否应该在领域模型层中创建领域服务以进行验证?

我们该如何处理?

提前致谢

最佳答案

I wonder if It is ok for domain entities to have access to repositories ?

不是真的 - 它会在您的组件之间造成依赖性纠结。

架构期望聚合在加载时具有保护其不变量所需的所有状态信息。参与修改聚合的任何其他状态都应作为参数传入。

因此,需要查询聚合边界之外的内容表明您的设计存在缺陷(您试图强制执行的约束不是“真实的”,聚合边界绘制在错误的位置,等等) .

使用域服务来支持聚合所需的查询比直接连接到存储库要好,但也好不到哪里去。域模型应该与环境隔离,但引入域服务(或存储库)以支持验证将域模型绑定(bind)到流程边界。

一个可以满足您需求的可接受的替代方案是让应用程序从存储库中获取必要的数据,然后将该数据的表示(或提供对该数据的访问的域服务)传递给聚合,这然后可以将其用于“验证”。

请注意,您有一个一致性问题 - 当您使用它的陈旧副本来“验证”您自己的更改时,其他一些聚合可能会更改位于远程的数据。如果您的聚合边界是正确的,那么这里的不一致对业务的成本应该是“小的”。

关键要点是状态检索和状态验​​证是不同的问题,并且了解聚合无法控制的任何状态必然是陈旧的——及时分离检索和验证不会向您的系统添加新的竞争条件.因此,将数据检索留在应用程序组件中,将验证放在聚合中,并接受您正在使用陈旧数据的权衡。

关于architecture - 在 DDD 中,域模型实体可以访问其存储库吗?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/41451277/

30 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com