我以StackOverflow为例，因为很明显你知道那个网站，我的真实用例非常接近。
让我们想象一下简化的SO域描述：
最后一个大胆的规则是对我很重要的规则。
我对AggregateRoot的理解是它应该包含用于决定接受或拒绝命令的状态，并且它不应该查询DB来执行此操作。它保证了应用程序的一致性。它应该只监听它发出的事件以更新其状态。
现在我认为SO域有一个名为Question的聚合根。 那个问题将处理如下命令：
问题是，当触发EditQuestion时，问题AggregateRoot如何能够决定是接受还是拒绝该命令？因为如果你还记得，如果你试图编辑另一个用户的问题，那么该命令应该被拒绝。 1000声誉。
对于我而言，问题AR维护所有用户声誉的列表，以便能够知道如何对该命令采取行动似乎并不让我感到理解。
问题在于，当我尝试对我的域进行建模时，我一遍又一遍地遇到这个建模问题，而且我总是最终得到一个大胖子AggregateRoot
有人可以告诉我我缺少什么并帮我解决这个问题吗？感谢
这question似乎说我们不应该将授权系统放在域模型中。我同意这对于基于角色的身份验证等问题可能很实用。但是，对我而言“用户无法编辑，除非他们有足够的声誉”实际上是一个SO业务规则，那么它怎么可能在域外？
重要提示：在回答时，请考虑您是业务专家。您知道StackOverflow是一个用户，可以自己猜出SO约束是什么。即使你对他们的看法不对，也不是什么大不了的事：只是为你错误的业务约束提出建议我就没事了!!!
这不是我第一次提出这样的问题而且总是没有答案，只是无休止的讨论。我想知道的是，如果您必须构建此站点，您将如何建模StackOverflow，重点关注有关要编辑的最低信誉的业务规则。