富域模型应用程序中的持久性和域层分离

Question

有一个概念是关于将persistent layer 与domain layer 分开以使domain layer 更加健壮-它不依赖于persistence layer 中存储库的实际实现，但仅在存储库界面上。

这意味着我们有：

IPersonRepository {...} // in domain layer
PersonCassandraRepository implements IPersonRepository {...}  // in persistence layer
Person (Aggregate Root) {...}

现在，Person 呢？

在anemic-domain-model 我们可以有：

IPerson {...} // in domain layer
Person implements IPerson {...} // in persistence layer

为什么要将 Person 放在 持久层？
因为它包含特定于实现的代码。
例如，它可能包含与 JPA 相关的注释，并且与存储库相同，我们不希望在我们的 域层中实现数据存储特定的实现。

我们可以使用 anemic-domain-model 来完成上述操作，因为 Person 不包含任何域逻辑，这意味着我们可以将 Person 放在 persistene 层。
在 anemic-domain-model 中，数据与行为是分离的，因此 Person 的行为是由分离的服务完成的，而不是写在 Person 本身中。

我们无法使用 rich-domain-model 进行这种层分离，因为在这种情况下，Person 确实包含特定于域的逻辑。

您将如何在 富域模型 应用程序中进行这种层分离？
或者您可能认为不需要它。

Answer 1

get(s) 持久化的类不一定是领域模型中的类（甚至实现相同的接口）。

因此，您可以在持久层中有一个 Person 类，该类旨在仅与持久层一起使用，并且没有实际行为，并且可能不强制执行域不变量。在您的领域层中，您有一个 Person 类，它确实强制执行不变量并且不知道持久性。

在这种方法中，存储库的职责是在持久层中Person 的表示和域层中Person 的表示之间进行转换。

Answer 2

您将如何在富域模型应用程序中进行这种层分离？ 或者您可能认为不需要它。

这是对话中既有文献倾向于说“哦，天哪，恐怕这就是我们今天的全部时间......”

---

设计是我们为了得到我们想要的东西而做的事情，而不是仅仅这样做。 -- 露丝·马兰

通常，您的业务逻辑并不关心管道的细节；运输集装箱（或其他）的业务策略与我们是否将信息存储在文件系统、关系数据库、文档存储或事件存储中无关......

所以我们“应该”在两层之间进行分离，以便我们可以轻松地将一层换成另一层。

但使这成为可能所需的设计工作并不是免费。如果您最终处于更改频繁且成本高昂的情况，那么您将不会玩得开心。

换一种说法：持久层和域层之间不必要的耦合是technical debt的一种形式，但承担技术债务可能是正确的决定。

---

IPerson {...} // in domain layer
Person implements IPerson {...} // in persistence layer

如果您想在域和持久性之间“分离”，这不太对；接口实际上并不是领域层的一部分，而是领域层所依赖的契约的一部分。

“富域模型”具有贫乏的数据模型。它可能是隐式的而不是显式的，或者隐藏在一堆包装器中，但如果深入挖掘，您几乎可以肯定会找到一个 int、double、bytes 或其他一些实际上没有实现的通用数据结构独立的领域逻辑。

当你将域和持久化分开时，你可以决定域层将使用持久化提供的贫乏的数据模型，或者你可以决定你只想跨越边界来回传递信息（值）。两者都可以，当然有不同的取舍。

---

推荐

• Boundaries（加里·伯恩哈特，2012 年）
• On the Complexity of JSON Serializers（Einar W. Høst，2020 年）
• At the Boundaries, Applications are not Object Oriented（马克·西曼，2011 年）