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

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 上的演讲。基本思想是领域模型不会试图阻止用户做事；相反，如果模型怀疑可能存在问题，它会专注于创建 "exception reports"。

在您的示例中，这可能看起来像是用户直接使用任务预算，使用 单独的聚合 异步观察变化到任务预算并根据需要更新活动和帐户预算。

同一基本思想的另一个观点是乌迪·达汉的文章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.

上的演讲中获得一些想法

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

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

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

您仍在更新您的记录簿，因此在 handle(Event) 的 CQS 意义上它仍然是 "command"，但您可以将 "capturing the event" 与 [=65= 分离]

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

Aggregate roots conflict in logic and performance

c#

.net

nested

domain-driven-design

aggregateroot