Domain driven design DDD-虚拟聚合根

有时我会遇到这种情况，当我有一堆实体域模型时，这些模型应该被事务性地持久化，但没有逻辑域模型可以成为所有这些实体域模型的聚合根

在这些情况下，有一个虚构的聚合根域模型是一个好主意吗？该模型没有类似的数据库实体，不会在数据库中持久化，但只在其自身中存储用于事务性持久化实体域模型的逻辑

另外，我之所以考虑这个问题，是因为让一个数据库表只存储一列聚合根ID对我来说似乎是错误的

在这些情况下，有一个虚拟的聚合根域模型是一个好主意吗？该模型没有类似的数据库实体，不会持久化到数据库中，但只在其自身中存储事务持久化实体域模型的逻辑

有点

拥有一个将组成聚合的实体连接在一起的

PurpleMonkeyDishchiner

非常好，这样您就可以确保数据保持一致并满足域不变

但它没有名字真的很可疑。这表明您并不真正理解您正在建模的问题

这是代码气味的建模等价物。可能有一个主题将这些实体安排在一起建模，不包括其他实体，而不是以其他方式。当您的领域专家一起讨论这些实体时，可能会用到一个名词。去找吧。这是工作的一部分。

一个“聚合根域模型没有类似的数据库实体，也不会持久化到数据库中”不是一个“虚拟聚合”；它是一个标准聚合，就像需要持久化的另一个聚合一样。聚合的目的是按照域规则控制更改，以确保一致性和不变量

有时聚合是变化的（需要持久化），但有时它不是变化的，变化后要持久化的东西是聚合内部发生变化的部分/完整实体和/或VO，它们自己在持久化中映射，而不需要构成持久化概念（表、文档等）。这是关于您决定如何持久化域数据的实现细节

DDD的第一个前提是：没有数据库。这有助于您在尝试映射域中的持久性概念时不要过于偏袒

迈克解释得比我好

我们的总体目标是控制变化，而不是控制变化。 是的，我们将数据组织为值对象或实体 但那是因为它是最容易维护的 我们对国家不感兴趣 就其本身而言，我们感兴趣的是确保预期的更改尊重 规则和为此，我们“借用”了领域思维，即我们 把事情看得好像我们是生意的一部分

聚合实例表明，对于一个聚合实例，一切都正常 特定的业务状态将发生变化。是的，我们需要坚持下去 业务状态发生变化，但这并不意味着聚合本身 需要持久化（可能的实现细节）。记住 聚合只是组织业务规则的构造， 它不是一个国家的代表

那么，如果聚合不是变化本身，那么它是什么？变化 表示为生成的一个或多个相关域事件 这些需要被记录（持久化）并且 应用（解释）。当我们应用事件时，我们“处理”事件 it的业务含义。这意味着某些价值已经改变或 可以触发业务场景

---

应用程序服务有什么区别？为了确保聚合在并发条件下的事务完整性，我们必须乐观地锁定聚合根。如果聚合根不可持久，我们怎么做？@PavelS和他的评论。你在混合概念和责任。一旦聚合应用了更改并说：好的，您必须捕获域事件中表示的更改，并使用它来应用持久性中的更改。聚合只是规则应用程序，不必对持久性实现有偏见。找到逻辑上包含所有实体的业务相关抽象很容易，这实际上是我的聚合根。我理解这一点DDD是一种非以数据库为中心的体系结构，但在我的例子中，我使用的是SQL数据库。这就是它的本质。对我来说，错误的是aggr根目录的表只有一个id列。