有时候，当我有一堆 实体域模型 时，我会遇到这种情况，它应该是事务性持久化的，但是没有逻辑域模型可以成为
在这些情况下，有一个 虚构的聚合根 域模型是一个好主意，该模型将没有类似的数据库实体，并且不会在数据库中持久存在但是会仅存储事务性持久 实体域模型的逻辑 ？
P.S。我认为这是因为拥有一个只存储一列聚合根id的数据库表似乎对我不利。
答案 0 :(得分：5)
在这些情况下，有一个虚构的聚合根域模型是一个好主意，该模型将不具有类比数据库实体，并且不会在数据库中持久化，但仅存储事务持久化实体域模型的逻辑吗？
排序。
将PurpleMonkeyDishwasher连接在一起组成汇总的实体组合在一起是完全没问题的，这样您就可以确保数据保持一致并满足您的域不变量。
但它真的很可疑它没有名称。这表明你并不真正理解你正在建模的问题。
这是代码气味的建模等价物。可能有一个主题将这些实体安排在一起，不包括其他实体，而不是其他一些安排。在讨论这些实体时，您的域专家可能会使用一个名词。去找吧。这是工作的一部分。
答案 1 :(得分：2)
“聚合根域模型，它将没有类比数据库实体，不会在数据库中持久存储”不“虚构汇总“;它是一个标准聚合，就像它需要持久化的另一个聚合一样。聚合的目的是控制域规则之后的更改，以确保一致性和不变量。
有时聚合 更改（并且需要保留）但有时不是，更改后要保留的内容是部分/完整实体和/或在聚合内部发生变化的VO，并在持久性中映射，而不需要编写持久性概念（table / s，document等）。这是关于您决定如何保留域数据的实现细节。
DDD的第一个前提：没有DataBase 。这有助于您不要过于偏向于尝试在域中映射持久性概念。
迈克在his blog解释它比我好。
我们聚合的目的是控制变化，而不是变化。 是的，我们将数据组织为Value Objects或Entity 引用，但这是因为它是最简单和最易维护的 强制执行业务规则的方法。我们对国家不感兴趣 本身，我们有兴趣确保预期的变化受到尊重 规则和我们正在“借用”域名思想，即我们 看看好像我们是业务的一部分。
聚合实例传达一切正常 特定的业务状态发生变化。而且，是的，我们需要坚持下去 商业状态发生了变化。但这并不意味着聚合本身 需要持久化（可能的实现细节）。记得 聚合只是一个组织业务规则的构造， 它并不意味着代表国家。
那么，如果聚合本身不是变化，它是什么？改变 表示为生成的一个或多个相关域事件 由汇总。那些需要记录（持久）和 应用（解释）。当我们申请活动时，我们“处理”了 它的商业含义。这意味着某些价值已经改变或a 可以触发业务场景。