общий дизайн и размер корня

Question

Я знаю, что есть миллион вопросов, подобных этому. Прости. Я думаю, что у меня разные, но, похоже, это не так. Я новичок в DDD и пытаюсь понять. Часть моего домена такая. Расположение 1- * Поле поле 1 * Событие поле 1 * Задача Задача - Сотрудник

теперь, казалось бы, что AR является Местоположение. и если бы я хотел получить конкретную задачу, мне пришлось бы перейти к задаче с помощью коллекции полей в коллекцию задач.

Это звучит довольно трудоемко, так как я имею дело с задачами и событиями много и почти никогда не с местом, где можно сказать. Местоположение служит для разделения группы полей и их соответствующих объектов. Поэтому в ui я могу выбрать место и получить список полей. Тогда я бы выбрал поле. Оттуда я мог бы отредактировать одну из ее задач. Поэтому у меня есть набор задач, и я выбираю один, поэтому у меня есть Id задачи. Затем мне нужно пройти до места и получить его идентификатор, чтобы я мог получить AR и вернуться к задаче. Вернее, я бы держал ИД АР, чтобы я мог его получить. Так должен ли я поддерживать Идентификатор поля? так что я вернусь на сервер, будет AR.Id, Field.Id и Task.Id, на которые я хочу посмотреть?

Во-вторых, сотрудник, конечно же, не мог быть сущностью, он скорее всего был бы AR. Хорошо ли для Entity в 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 
} 

Это делает его гораздо легче иметь дело с объектами, которые изменяются наиболее и пересекать их отношения, но он также чувствует себя вроде как обычная старой ООП и что AR самом деле не означает ничего.

Снова я новичок в DDD и не имею никого, кто мог бы запустить это для проверки работоспособности. Пожалуйста, помогите мне понять, как эти границы нарисованы, и если это первый способ, есть более простой способ справиться с обработкой сущностей, а затем переносить AR.id, ParentParent.Id, ParentId и, наконец, объект интерес Entity.Id

Спасибо за любые мысли R

Answer 1

Ok, на некоторых более прибегая к помощи я нашел эту серию статей.

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

, чтобы добраться до части 2 и так далее просто изменить последний didgit в ссылке.

Здесь я обнаружил, что, как указывает Ив, я не понял цели Агрегатов и совокупных корней. Оказывается, они хотят поддерживать согласованность между связанными сущностями, а не просто объединяют кучу сущностей, которые имеют отношения друг с другом.

Так что, если в поле может быть только 3 Задачи в любой день, то поле будет хорошим кандидатом для AR, так как если бы вы просто добавляли Tasks волей-неволей, вы могли бы легко создать недопустимое состояние в системе, как если бы вам нужно было добавить задачу с помощью метода в поле, тогда легко проверить, приемлемо ли это.

Далее следует избегать гигантских совокупных корней, потому что они требуют много ресурсов для загрузки и могут вызывать проблемы с параллелизмом.и т. д. и т. д., читайте статьи, которые они рассматривают по моему вышеуказанному вопросу красиво.