【发布时间】：2012-08-05 16:39:49
【问题描述】：
可能是某些域逻辑实现实体需要访问 repo 以更新/删除自身或任何相关实体。这听起来对吗？？
【问题讨论】：
标签： domain-driven-design ddd-repositories
【发布时间】：2012-08-05 16:39:49
【问题描述】：
不，它没有，至少对于带有 "domain-driven-design" 标签的问题。 当然，Active Record 模式有权存在于某些系统中，并且有些人发现强耦合很有用，但在 DDD 中建议的方式是显式使用存储库：
Evans DDD，第 152 页：对于需要全局访问的每种类型的对象，创建一个可以提供该类型所有对象的内存集合假象的对象。 «...» 仅为实际需要直接访问的聚合根提供存储库。让客户专注于模型，委托所有对象存储和对存储库的访问。
因此，在 DDD 中，存储库不仅封装了访问数据库所需的基础架构代码，还封装了必须存储和加载对象的整个想法。
如果您正在执行一些涉及从数据库保存和加载的复合操作，那么引用 存储库 的服务 是最佳候选。
【讨论】：
-
感谢 Boris 的回复，也许我应该详细说明这个问题的来源，请查看这个解释我的场景的问题 stackoverflow.com/questions/11643636/soft-delete-in-ddd 并让我知道你的想法
-
而且因为你提到它，我一直听到关于 DDD 的意见，说如果你正在做一个普通的 CRUD 类型的应用程序，不要使用 DDD。我发现 DDD 的一些一般准则具有通用性，无论我是否已经发展出一种“普遍存在的语言”（我认为总是有一个 UL，即使词汇表包含相当技术性的术语，如插入、更新、删除 - 例如我的域专家实际上使用这些术语:)）
-
@redzedi pein 的回答很好，我只是为实体引入一个状态（或状态）字段，实体将有一个 cancel() 方法，它将其状态更改为 CANCELLED，恕我直言它与存储库 CRUD 方法无关。当然，当有人取消发票或任何将使用 Save() 方法保存的发票时。
-
Evans 在他的书中某处指出，不存在使用书中所有实践的项目，因此您无法实现 100% 的 DDD 系统 - 无论如何这都是平衡和常识的问题
-
@redzedi 我看过你最近的question 所以请检查another answer 我不认为在调整框架上付出很多努力有什么好处，因为总是有风险最终开发出expert system :-)
虽然实体能够访问自己的存储库以存储或删除自身听起来确实很危险（请参阅persistence ignorance），但在某些特定情况下，我可以容忍实体异常请求从一个 Repository another 聚合根，它还没有持有对它的引用。
但是，请注意，域实体应该只知道存储库的抽象（即驻留在域层中的接口），而不是它们的具体实现。因此，不要让 Domain 层引用 Infrastructure 层，而是在运行时在需要它们的地方注入具体存储库的实例。
无论如何，这不应该成为常态。
【讨论】：