c# - 聚合根在逻辑和性能上的冲突

Question

问题来了:我们有一个用户与任务交互的项目。但每个任务都是事件的一部分，每个事件都存在于一个帐户中。因此，在我看来，使帐户成为聚合根似乎是合乎逻辑的(因为没有事件就不可能存在任务，而没有帐户就不可能存在事件)。

帐户、事件和任务有某种预算，必须有可供用户执行的任务的预算。所以我想是这样的:

class Account{
    Budget Budget;
    List<Campaign> Campaigns;
    // Account stuff
}

class Campaign{
    Budget Budget;
    List<Mission> Missions;
    // Campaign stuff
}

class Mission{
    Budget Budget;
    double Value;
    // Mission stuff
}

这对域逻辑来说是有意义的，但我很难让用户直接处理任务，因为他们不关心事件或帐户。还有多个帐户，我需要向用户提供他们可以执行的所有任务。加载所有这些实体变得繁重而复杂，所以我考虑还原所有内容并像这样完成任务:

class Mission{
    Budget AccountBudget;
    Budget CampaignBudget
    Budget MissionBudget
    Double Value;
    // All mixed stuff that i need
}

所以我只有一个任务存储库，它可以更轻松地与所有任务和用户一起工作，但是当执行任务时，我需要更新所有任务的帐户和事件预算。对于域逻辑，这种结构对我来说也不太有意义。那么，如果我选择第一个解决方案，我如何避免性能问题并让用户获得所有可用任务呢？如果我选择第二种解决方案，它有意义吗？

Answer 1

So to me seems logical to make the account an aggregate root (since a mission cannot exist without a campaign and a campaign cannot exists without an account).

在实践中，这似乎不是一个特别好的启发式方法；将域划分为聚合体与其说是结构，不如说是关于行为。您是否需要知道帐户的详细信息才能更改任务？您是否需要了解任务的详细信息才能更改帐户？

i'm having troubles to allow users work directly with missions, since they don't care about the campaign or the account.

这是一个很大的暗示，任务也许是一个单独的集合；如果您希望许多用户同时操纵他们的任务而不踩到彼此的脚趾，情况尤其如此。

when a mission gets executed i need to update the account and campaign budget for all missions.

是的，但是需要立即，还是很快？

您可能应该回顾一下 Greg Young 在 warehouse systems 上的演讲.基本思想是领域模型不会试图阻止用户做事；相反，它专注于在模型怀疑可能存在问题时创建“异常报告”。

在您的示例中，这可能看起来像用户直接使用任务预算，使用单独的聚合异步观察任务预算的变化并更新事件和帐户预算。

相同基本思想的另一个观点是 Udi Dahan 的论文 Race Conditions Don't Exist

A microsecond difference in timing shouldn’t make a difference to core business behaviors.

您有许多用户更新任务预算；这意味着他们协作与帐户预算进行交互。因此，您应该考虑允许这种协作在没有用户争用的情况下发生的设计。

我的猜测是，您最终会发现自己的Mission 结构如下

class Mission{
    AccountId accountId;
    CampaignId campaignId;
    MissionId missionId;

    Budget Budget;
    // Mission stuff
}

Do you have any suggestion about a design to allow users collaboration on a shared resource or some sources to look up?

我不觉得那里有很多东西。您或许可以从 Greg Young 在 occasionally connected systems 上的演讲中获得一些想法。 .

还有一种方法可以将来自外部世界的消息视为命令；您可以将它们视为事件:UserDecided、UserSubmittedForm....所以外部世界是记录簿，您的聚合行为像下游事件处理器

Alice said X
Bob said !X (contradicting Alice)
... and therefore (other consequences)

其他后果可能会升级到人类身上，或者这两个决定相互抵消，或者......

您仍在更新您的记录簿，因此它仍然是 CQS 意义上的“命令”handle(Event)，但您可以将“捕获事件”与“执行”分离关于事件"