domain-driven-design - 事件源链事件

Question

我正在使用事件源实现有限的上下文，但是遇到了一个问题。假设我正在为足球比赛建模，并且我对得分的个人目标(谁得分了等等)和整体得分都感兴趣。因此，如果我有一个Match聚合根，则理想情况下，我希望引发称为GoalScored和ScoreChanged的事件。我想要像这样从领域中明确说明分数的原因是，我不需要很多不同的监听器，也可能不需要其他有界上下文都计算相同的内容。

这似乎很简单，但是:Match对象具有一个Goal()方法，该方法添加了一个新的目标。本着事件源的精神，这并不直接改变Match状态，而是引发一个在Match中处理的GoalScored事件，该事件随后会改变状态(以及将事件推送到非规范化器)。因此，就引发ScoreChanged而言，在处理了GoalScored事件之前，分数实际上并没有改变，那么我是否应该针对该事件引发另一个事件(ScoreChanged)，以有效地链接事件呢？我不这么认为，首先是从事件存储中重新加载聚合根时，每次响应每个GoalScored都会创建很多额外的事件。

我还考虑过弄清楚在提高GoalScored的命令处理程序中的得分是什么样的情况。然后，我可以在命令处理程序中引发这两个事件。我真的不愿意这样做-它看起来似乎不是“正确”。计算分数对于足球来说已经足够简单了，但是其他游戏(例如板球)则需要做更多的工作。

我可以将目标和得分都放到GoalScored事件中，这很公平，但是似乎也不正确-得分本身与GoalScored事件无关。

讨论事件源时使用的所有示例似乎都使用了“电子商务客户/订单”域，而我从未见过类似的案例。

有没有人有处理这种情况的经验？

谢谢

Answer 1

像其他建模一样，选择干净的域事件应导致在域中镜像的概念。您说“分数本身与GoalScored事件无关”。但是，确实如此。在足球比赛中，唯一可以改变得分的方法就是进球。不过，可以收回目标，例如通过越位通话或其他处罚。目前尚不清楚是否要对此建模。

域方法通常一次发出多个事件是很常见的。一个好的框架将使他们很容易被视为一堆，例如作为一次提交。为什么不同时发出GoalScored事件和ScoreChanged事件？

您可能还需要考虑该域是否根本没有任何命令。足球比赛本身就是记录系统。比赛产生的事件已经是历史记录了。您也许只是在编写一个将事件流处理为更多事件流的系统？