当使用Parent-Child-GrandChild ...关系的事件采购时,CQRS读取模型设计

Question

我正在编写我的第一个CQRS应用程序,假设我的系统调度了以下命令:

• CreateContingent(Id,Name)
• CreateTeam(Id,Name)
• AssignTeamToContingent(TeamId,ContingentId)
• CreateParticipant(Id,Name)
• AssignParticipantToTeam(ParticipantId,TeamId)

目前,这些导致相同的事件,仅用过去时(WorgentCreated,TeamCreated等)措辞,但它们包含相同的属性.(我不确定这是否正确,这是我的一个问题)

我的问题在于阅读模型.

我有一个Contingents读取模型,订阅了ContingentCreated,并具有以下方法:

    List<ContingentQueries.Contingent> GetContingents();
    ContingentQueries.Contingent GetContingent(System.Guid id);
    ContingentQueries.Contingent GetContingent(string province);

这些返回的Contingent类看起来像这样:

    public class Contingent
    {
        public Guid Id { get; internal set; }
        public string Province { get; internal set; }
    }

这适用于列表,但是当我开始考虑单个特遣队及其所有团队的视图的读取模型时,事情开始变得混乱.鉴于这些方法似乎微不足道:

    ContingentQueries.Contingent GetContingent(System.Guid id);
    ContingentQueries.Contingent GetContingent(string province);

我使用一组团队为这些查询创建了Contingent类:

    public class Contingent
    {
        public Guid Id { get; internal set; }
        public string Province { get; internal set; }
        public IList<Team> Teams { get; internal set; }
    }

    public class Team
    {
        public Guid Id { get; internal set; }
        public string Name { get; internal set; }
    }

从理论上讲,我只需要订阅ContingentCreated和TeamAssignedToContingent,但TeamAssignedToContingent事件只有团队和偶然ID ...因此我无法设置此读取模型的Team.Name属性.

我是否也订阅了TeamCreated？添加另外一组团队在这里使用？

或者当事件被提出时,他们是否应该有更多信息？AddTeamToContingent命令处理程序是否应该查询要添加到事件的团队信息？这可能还不存在,因为读取模型可能尚未与团队一起更新.

如果我想显示团队名称和已分配给团队的参与者,并在此特遣队视图中命名队长,该怎么办？我是否也将参与者存储在阅读模型中？这似乎有点重复.

对于一些额外的背景.参与者不一定是任何特遣队或团队的一部分,他们可能只是客人; 或特遣队的代表和/或备件.但是,角色可以改变.非团队成员的代表也可能是一名备用人员,由于受伤将被分配给团队,但他们仍然是代表.这就是使用通用"参与者"的原因.

我理解我希望阅读模型不要超过必要的重量,但是我可能需要从我没有订阅的事件(TeamCreated)中获取数据这一事实有困难,理论上不应该,但是因为未来事件(TeamAssignedToContingent)我确实需要这些信息,我该怎么办？

更新:一夜之间想到这一点,似乎我所想到的所有选项都很糟糕.必须有另一个.

选项1:向引发的事件添加更多数据

• 命令处理程序是否开始使用可能尚未编写的读取模型,以便获取该数据？
• 如果该活动的未来订阅者需要更多信息,该怎么办？我无法添加它!

选项2:让事件处理程序订阅更多事件吗？

• 这导致读模型存储它可能不关心的数据？
• 示例:将参与者存储在ContingentView读取模型中,这样当一个人被分配到团队并标记为队长时,我们就知道他们的名字.

选项3:让事件处理程序查询其他读取模型吗？

• 这感觉就像最好的方法,但感觉不对.如果需要,"条件"视图是否应查询"参与者"视图以获取名称？它确实消除了1和2中的draback.

选项4:......？

Answer 1

您可能最终得到的是1和2的组合.增强或丰富事件以获得更多信息绝对没有问题.这实际上非常有帮助.

• 如果该活动的未来订阅者需要更多信息,该怎么办？我无法添加它!

您可以将其添加到未来的事件中.如果您需要历史数据,则必须在其他地方找到它.您不能仅仅根据将来需要的事件来构建包含世界上所有数据的事件.甚至允许返回并向您的历史事件添加更多数据.有些人会对此作为重写历史,但你不是,你只是在改善历史.只要您不更改现有数据,您应该没问题.

我怀疑你的事件处理程序也需要随着时间的推移订阅更多事件.例如,团队是否需要重命名？如果是这样,那么你将需要处理该事件.不要害怕在不同的读取视图中拥有相同数据的多个副本.来自关系数据库背景,这种重复数据是最难以使用的事情之一.

最后要务实.如果您在应用CQRS时遇到痛苦,那么请更改您应用它的方式.