1

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

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

这听起来很费力，因为我经常处理任务和事件，而且几乎从来没有一个位置。该位置用于隔离一组字段及其对应的实体。所以在 ui 中，我可以选择一个位置并获取字段列表。然后我会选择一个领域。从那里我可能会编辑其中一项任务。所以我有一组任务，我选择一个，这样我就有了任务的 ID。然后我需要遍历到 location 并获取他的 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

感谢您的任何想法

4

1 回答 1

3

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

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

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

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

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

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

于 2012-06-25T21:31:38.527 回答