持久性无知和 DDD 现实

Question

我正在尝试不费吹灰之力地实现完全有效的持久性无知。不过我有很多问题:

最简单的选项

这真的很简单——可以像在 SOA 中那样使用 Spring Data 注释对实体进行注释(但让它们真正执行逻辑)？除了必须在实体中使用持久性注释之外还有什么后果，这并不真正遵循 PI 原则？我的意思是 Spring Data 真的是这样 - 它提供了很好的存储库，可以完成 DDD 中的存储库应该做的事情。问题在于实体本身......

更难的选择

为了使实体不知道它所操作的数据来自何处，很自然地通过构造函数将该数据作为接口(interface)注入(inject)。另一个优点是我们总是可以执行延迟加载——例如，我们在 Neo4j 图形数据库中默认拥有。缺点是聚合(由实体组成)将完全了解所有数据，即使它们不使用它们 - 由于数据完全暴露，可能会导致调试困难(DAO 将像聚合一样是分层的)。这也将迫使我们为存储库使用一些适配器，因为它们不再存储真实的实体......而且任何翻译都很丑陋......另一件事是我们无法在没有这样的 DAO 的情况下实例化实体 - 尽管可能存在-域中的内存实现......再次，更多层。有人说注入(inject) DAO 也会破坏 PI。

最难的选择

实体可以包裹在一个决定数据应该来自哪里的延迟加载器上。它可以是内存中的，也可以是数据库中的，它可以处理任何需要事务的操作等等。虽然是复杂的层，但在某种程度上可能是通用的......？阅读一下 here

你知道其他解决方案吗？或者，也许我在提到的那些中遗漏了一些东西。请分享你的想法!

Answer 1

作为正确域建模的副作用，我(几乎)免费实现了持久性无知。

尤其:

如果您正确定义了每个上下文的边界，您将获得不需要延迟加载的小实体(这实际上成为 DDD 项目中的反模式/代码气味)

如果您不能简单地将 SQL 使用到您的存储库中，请将一组 DTO 映射到您的数据库模式，并将它们用于工厂以初始化实体类。

在 DDD 项目中，持久性无知与领域模型本身有关，与存储库、工厂和其他应用程序代码无关。实际上，您将来不太可能更改 ORM 和/或数据库。

仅限 (但非常强)持久性背后的理性 对领域模型的无知是关注点分离:在领域模型中，您应该表达业务不变量 仅限 !持久性是一个基础设施问题!

例如，如果没有持久性无知(以及延迟加载)，域模型应该处理来自数据库的可能异常，它的复杂性会增加，并且业务规则会隐藏在技术细节下。