Question

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

现在似乎AR是位置。如果我想得到一个特定的任务，我将不得不通过收集任务集合中的字段集来遍历任务。

这听起来非常费力，因为我经常处理任务和事件，而且几乎从来没有说过每个人的位置。该位置用于隔离一组字段及其对应的实体。所以在ui中，我可以选择一个位置并获取字段列表。然后我会选择一个领域。从那里我可以编辑其中一个任务。所以我有一系列任务，我选了一个，所以我有任务的ID。然后我需要遍历到位置并获得他的身份证，以便我可以获得AR并逐步回到任务。或者更确切地说，我会保持AR的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，最后是对象兴趣Entity.Id

感谢您的任何想法 [R

Answer 1

好的，经过一些谷歌搜索，我发现了这一系列精彩的文章。

http://dddcommunity.org/sites/default/files/pdf_articles/Vernon_2011_1.pdf

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

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

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

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

聚合根设计和大小

1 个答案: