0

有一个概念谈到了将 与 分离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 放在持久层中。
在贫血域模型中，数据与行为是分离的，因此 Person 的行为是由分离的服务完成的，而不是写在 Person 本身中。

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

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

4

2 回答 2

0

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

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

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

于 2021-12-11T14:04:40.170 回答
0

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

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

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

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

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

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

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

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

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

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

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

推荐的

于 2021-12-11T20:19:06.270 回答