domain-driven-design - DDDD:事件数据

Question

我正在努力解决 DDDD 在 Greg Young的风格 .

有很多关于如何实现的讨论 DDDD 与 CQRS+EventSourcing 并且有一些示例实现......总的来说它可能会很困惑......

在格雷格 View 聚合没有 getter 或 setter - 只是发出相应事件的状态更改方法。

基本上是一个事件 描述了 状态转换 那发生在过去。它的数据描述了发生了什么变化。

有人说，此数据可以通过附加数据“丰富” .
在哪里 这个额外的数据可以来吗来自 ?

即我有 User 和 Usergroup - 两个聚合根 (可以独立存在，有身份)。 User有一个名为 AddToUsergroup 的方法.

public class User : AggregateRoot
{
    // ...
    public void AddToUsergroup(Usergroup usergroup)
    {
        // validate state
        RaiseEvent(new UserJoinedUsergroup(this.Id, usergroup.Id));
    }
    // ...
}

public class Usergroup : AggregateRoot
{
    private string _displayName;
    // ...
    public void ChangeDisplayName(string displayName)
    {
        // validate state
        RaiseEvent(new DisplayNameChanged(this.Id, displayName));
    }
    public void Apply(DisplayNameChanged e)
    {
        this._displayName = e.DisplayName;
    }
    // ...
}

如果我想“ 丰富 ” 事件 与 用户组名称 (出于调试原因或类似原因)，我该怎么做？

setter/getter 是 不存在

内部状态 用户组的 无法访问

注入(inject) 诸如 之类的东西存储库 进入 User是 不允许 ( 我在这里吗？!？ )，比如

读取端存储库

事件存储库

底线问题:

可以应该像 存储库 是 注入(inject)聚合根？

如果有事件 仅限 使用 可通过参数和内部状态获得数据 的总量？

应事件 仅限 包含最小数据 描述状态变化？

而且(有点离题，但样本在这里)

应该 AddToUsergroup采取指导 而不是 全聚合根 ?

期待您的回答!

LG
瓦拉帕

Answer 1

Should something like repositories be injected to aggregate roots?

不，在这种情况下也没有必要。将域服务传递给聚合上的行为方法可能是合适的，但同样在这种情况下不需要。

Should a event only use data available through parameters and internal state of the aggregate?

是的，原始领域事件应该可以很容易地由聚合构建，并且可以以确定性的方式重播。

Should events only contain the minimum data describing the state-change?

是的。然而，为了满足外部订阅者的需求，这里是 content enricher发挥作用。要从外部分派(dispatch)域事件，首先将其提交到事件存储，然后您可以在同一个 tx 中分派(dispatch)或使用进程外机制将事件发布到外部。在外部发布时，您通常会为消息使用不同的契约(Contract)，因为订阅者可能需要的不仅仅是域事件本身的内容。在这种情况下，您需要用户组名称。然后，发布者可以提取用户组名称并将该数据放入丰富的事件中。此发布者可以访问允许其检索名称的用户组的读取模型存储库。

Should AddToUsergroup take an Guid instead of an full aggregate root?

是的。传递整个聚合可能是不可能的，并且还会产生一种错觉，即可以使用 ID 以外的东西，但事实并非如此。