聚合根设计和大小

Question

我知道有一百万个这样的问题。对不起。我认为我的不一样，但似乎并非如此。我是 DDD 的新手，并试图掌握它。 我的部分域是这样的。 位置 1-* 字段 字段 1-* 事件 字段 1-* 任务 任务 - 员工

现在看来，AR 就是位置。如果我想完成一项特定的任务，我将不得不通过任务集合中的字段集合遍历任务。

这听起来很费力，因为我经常处理任务和事件，而且几乎从来没有说位置。该位置用于隔离一组字段及其对应的实体。所以在 ui 中，我可以选择一个位置并获取字段列表。然后我会选择一个领域。从那里我可能会编辑其中一项任务。所以我有一组任务，我选择一个，这样我就有了任务的 ID。然后我需要遍历到某个位置并获取他的 ID，这样我才能获取 AR 并遍历回任务。或者更确切地说，我会保留 AR 的 ID，以便我可以得到它。那么我是否也应该保留该字段的 ID？那么我返回给服务器的将是我要查看的 AR.Id、Field.Id 和 Task.Id？

其次，员工当然不能是实体，它很可能是 AR。 AR 上的实体可以拥有 AR 的集合吗？

所以也许它的结构应该是这样的？

public class Location  // is an aggregate Root
{
    public IEnumerable<Field> Fields {get;set;} //in real code encapsulated. not here for brevity
}
public class Field  // is an Aggregate Root
{
    public Location Location {get;set;}  //reference to AR
    public IEnumerable<Task> Tasks {get;set;}
    public IEnumerable<Events> Events {get;set;}
}
public class Task // is an Aggregate Root
{
    public Field Field {get;set;}  // reference to AR
    public IEnumerable<Employee> Employees {get;set;}
    public TaskType TaskType {get;set;}  // probably Value Object
    public IEnumerable<Equipment> Equipment {get;set;}  // maybe Entity or AR
} 

这使得处理修改最多的对象和遍历它们的关系变得更加容易，但它也有点像普通的旧 OOP，AR 并没有真正的意义。

再一次，我是 DDD 的新手，没有人可以通过它来进行健全性检查。请帮助我了解这些边界是如何绘制的，如果是第一种方法，是否有更简单的方法来处理实体，然后携带 AR.id、ParentParent.Id、ParentId 以及最后的对象兴趣实体.Id

感谢您的任何想法 回复

Answer 1

好的，通过更多的谷歌搜索，我发现了这个很棒的系列文章。

https://dddcommunity.org/wp-content/uploads/files/pdf_articles/Vernon_2011_1.pdf

要进入第 2 部分等等，只需更改 url 中的最后一个 didgit。

在这里我发现，就像 Yves 指出的那样，我误解了聚合和聚合根的目的。事实证明，它们是关于保持相关实体之间的一致性，而不是仅仅将一堆相互关联的实体捆绑在一起。

因此，如果一个字段在任何一天只能有 3 个任务，那么一个字段将是 AR 的一个很好的候选者，因为如果您只是随意添加任务，您可以很容易地在系统中创建一个无效状态，其中如果您必须通过 Field 上的方法添加任务，则可以轻松检查这是否可以接受。

另外一个人想要避免巨大的聚合根，因为它们需要大量的资源来加载，并且可能导致并发问题。等等等等阅读了他们很好地解决了我上述问题的文章