DDD: Large Aggregate Root - Person

Question

Я создаю систему для управления информацией о человеке. У меня постоянно растущий совокупный корень, называемый Лицом. Теперь у меня есть сотни связанных объектов, имя, адреса, навыки, отсутствие и т. Д. Меня беспокоит то, что Person AR одновременно ломает SRP и создает проблемы с производительностью, поскольку все больше и больше вещей (коллекции esp) добавляются к нему.

Я не вижу, как с помощью DDD разбить это на более мелкие объекты. На примере отсутствия. У человека есть коллекция записей отсутствия (начало, конец, причина). В настоящее время они управляются через Person (BookAbsence, ChangeAbsence, CancelAbsence). При добавлении отсутствий мне необходимо проверить все остальные абзацы, поэтому для выполнения этой проверки мне нужен объект, который имеет доступ к другим абзацам.

Я что-то упустил? Есть ли еще один AR, который я не идентифицировал? Раньше я бы это сделал с помощью службы «AbsenceManager», но хотел бы сделать это с помощью DDD.

Я довольно новичок в DDD, поэтому, возможно, я чего-то не хватает.

Большое спасибо ....

Answer 1

Отсутствие chould быть смоделирована как совокупность. A AbsenceFactory подходит для проверки на другие Отсутствие с, если вы хотите добавить новый Отсутствие.

Пример кода:

public class AbsenceFactory { 
    private AbsenceRepository absenceRepository; 
    public Absence newAbsenceOf(Person person) { 
     List<Absence> current = 
       absenceRepository.findAll(person.getIdentifier()); 
     //validate and return 
    } 
} 

Вы можете найти эту модель в синей книге (раздел 6.2 Factory, если я не ошибаюсь)

В других «изменить» случаи, вы могли бы ввести Спецификация

public class SomeAbsenceSpecification { 
    private AbsenceRepository absenceRepository; 

    public SomeAbsenceSpecification(AbsenceRepository absenceRepository) { 
     this.absenceRepository=absenceRepository; 
    } 

    public boolean isSatisfiedBy(Absence absence) { 
      List<Absence> current = 
       absenceRepository.findAll(absence.getPersonIdentifier()); 
     //validate and return 
    } 
} 

Вы можете найти эту модель в синей книге (раздел 9.2.3 Спецификация)

Answer 2

Это действительно то, что делает сложный дизайн настолько сложным. Собственность не обязательно означает агрегацию. Нужно понять домен, чтобы иметь возможность дать правильный ответ, поэтому мы пойдем с хорошим примером «Order». A Customer не будет иметь коллекции Order объектов. Самое простое правило - подумать об удалении AR. Те объекты, которые могут иметь смысл при отсутствии AR, вероятно, не принадлежат AR. A Customer может очень хорошо иметь коллекцию ActiveOrder объектов. Конечно, был бы инвариант, заявляющий, что клиент не может быть удален, если он имеет активные заказы.

Еще одна вещь, которую нужно обратить внимание - это раздутый ограниченный контекст. Можно предположить, что у вас может быть один или несколько ограниченных контекстов, которые не были идентифицированы, что приводит к ситуации, когда у вас слишком много АР.

Так что в вашем случае вы все равно можете быть заинтересованы в Absence, если удалите Customer. В случае OrderLine он не имеет смысла без его Order. Так что никакого жизненного цикла.

Надеюсь, что это помогает.

Answer 3

Я строю систему для управления информацией о человеке.

Вы уверены, что простое приложение CRUD, которое редактирует/обрабатывает таблицы RDBMS через SQL, не было бы более дешевым подходом?

Если вы можете выразить большинство бизнес-правил в отношении отношений данных и операций с таблицами, вы вообще не будете использовать DDD.

У меня постоянно растущий агрегатный корень, называемый Лицом.

Если у вас действительно есть сложные бизнес-правила, постоянно растущий совокупный часто syntom неопределенной (или неправильно определен) context boundaries.