DDD 综合问题 (.NET, EF)答案

【问题标题】：DDD Aggregate Question (.NET, EF)DDD 综合问题 (.NET, EF)
【发布时间】：2011-08-11 12:48:02
【问题描述】：

我的域模型（简化）包含故事、团队、成员和 cmets。我现在需要允许用户写关于故事的评论，并且我有属于故事聚合的评论实体，所以我在 Story 上有一个名为“AddComment”的方法。在这里加载聚合以保存评论似乎很愚蠢，所以我想知道是否应该从聚合中删除这个实体，或者这里有什么我遗漏的东西？我确信我会遇到不止一种此类场景，所以任何帮助都会很棒！

谢谢

【问题讨论】：

评论仅与故事相关还是实际上是一个独立的集合？
如果故事回答了你的问题，评论就不可能存在。

标签： .net domain-driven-design aggregate

【解决方案1】：

Marco，克制住允许技术实现对您的域模型进行类似更改的冲动。每次我这样做了，我后来都后悔了。如果 Comments 仅存在于 Stories 中，则将 Story 保留为聚合并弯曲技术以匹配模型。

【讨论】：

当您说弯曲技术时，您的意思是例如，在 EF 中，弄清楚如何在不首先获取实体的情况下完成此操作？
这可能行不通，但是通过延迟加载，您至少可以避免拉入所有相关实体（如所有现有的 cmets）。它可能不如直接插入 cmets 表那么有效，但拥有丰富的、可测试的模型通常值得一些权衡。
那么你更喜欢延迟加载还是急切加载？您的服务层是否“知道”根据其任务急切加载哪些实体？
我的团队使用 NHibernate。我们一开始默认没有延迟加载。随着模型变得越来越复杂，我们必须进行延迟加载，以使我们不必考虑我们尝试做的每件事都需要哪些关系。我们可以将我们的模型视为一直在内存中，而存储库模式使这种错觉成为可能。
顺便说一句，这些斗争让我对事件溯源更感兴趣，因为它是我的领域模型的基础。如果你想吃红色药丸，你可以从cqrsinfo.com/documents/cqrs-and-event-sourcing-synergy开始。

【解决方案2】：

如果评论不能在没有故事的情况下存在，那么为什么加载故事以保存评论似乎很愚蠢？而且您实际上并没有保存评论，而是将其添加到故事中，然后保存了故事。

通常，当您发现自己有这些文件时，您做了不必要的事情来执行操作，这表明您的域模型可能需要更多改进。回顾你所有的一致性边界要求（聚合），检查模型中的每个有界上下文，也许你在第一次通过时错过的东西会浮出水面。

正如 Eric Evans 所说，DDD 是一个迭代过程。前几次你会失败:)

【讨论】：

看this video不会浪费一小时