domain-driven-design - DDD - 虚构的聚合根

标签 domain-driven-design aggregateroot

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

在这些情况下,拥有一个 虚构的聚合根 域模型是否是一个好主意,该域模型将没有类似的数据库实体并且不会在数据库中持久化,但会仅存储用于事务持久化实体域模型的逻辑?

附:我之所以坚持这一点,是因为让一个数据库表只存储一列聚合根 ID 对我来说似乎是错误的。

最佳答案

Is it a good idea in these cases to have a fictitious aggregate root domain model which will have NO analogical database entity and will not be persisted in the database but will store in itself only logic for transactionally persisting entity domain models ?

有点。

最好有一个 PurpleMonkeyDishwasher 将构成聚合的实体组合在一起,这样您就可以确保您的数据保持一致并满足您的域不变性。

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

这是代码异味的建模等价物。可能有一个主题将这些实体安排在一起建模,排除其他实体,而不是其他一些安排。您的领域专家在谈论这些实体时可能会使用一个名词。去找吧。这是工作的一部分。

关于domain-driven-design - DDD - 虚构的聚合根,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/46935567/

相关文章:

domain-driven-design - DDD : aggregate root question

domain-driven-design - 多个域对象和存储库来支持同一实体的不同用途?

many-to-many - DDD : nested aggregates and many to many relationships

domain-driven-design - 领域驱动设计——如何为公司和员工用例建模?

domain-driven-design - 处理 DDD 中的嵌套聚合

c# - EntityFramework 和 IoC 接口(interface)在洋葱架构中属于什么位置?

.net - 如何实现DDD存储库以处理具有多个实体的查询?

java - 限制对 DDD 中对象所有者的访问

c# - 从聚合根和数据库持久性中删除子项