Как определить совокупные и агрегированные корни и ссылку между агрегатами

Question

Итак, я новичок в DDD, и я пытаюсь правильно разработать приложение. Но я испытываю трудности с определением совокупных корней.

Моя потребность более или менее дерево

*Customers 
*Each customer can have 0 or more licenses 
*Each license can have 0 or more courses 
*Each course can have 0 or more lessons 
*Each lesson can have 0 or more slides and videos 

Наконец у меня есть тесты/тесты, которые могут быть связаны с почти ничего, даже некоторое время на видео в уроке.

Независимо от того, как я думаю об этом, я только получить, что Клиент будет совокупный корень для агрегата, который содержит [Клиент, лицензия, курс, урок, слайд, видео]

Но это довольно большой агрегат и я понял, что следует избегать больших агрегатов.

Тогда викторина будет представлять собой совокупность вопросов, ответов и т. Д. В качестве второго вопроса я могу спросить, как должна выглядеть ссылка? потому что позволяет сказать, что я хочу, чтобы викторина появлялась в видео через 4 минуты. Ну, тогда моя викторина должна связать это видео и сохранить время. Но это видео находится в глубине другой совокупности (по клиенту, лицензии, курса, урока) и не должно быть связано напрямую с этим агрегатом викторины.

Так как я могу это решить. Я заказал свою большую книгу DDD, но она не будет здесь некоторое время. Если бы я мог понять это раньше, это было бы здорово!

Я не думаю, что это важно, но я использую .net C# mvc, с шаблоном ef5 и репозиторием.

Answer 1

Чтобы упростить работу, вы должны использовать CQRS. Используйте разные модели для написания и для запросов. Это означает, что мы имеем 2 случая 1. Создание и обновление бизнес-объектов (лиц) 2. порождающие упрощенную модель из бизнес-объектов, чтобы просто запрашивая

Используя этот подход означает, что вы можете сосредоточиться на моделировании клиента, лицензия , Курс, Уроки строго для пурпуса моделирования реального поведения и отношений между ними.

Здесь легко попасть в подход, ориентированный на данные, где Клиент рассматривается как контейнер для лицензий, который, в свою очередь, является контейнером для курсов и т. Д. Это довольно очевидно (даже без большой информации), что эти сущности являются совокупными корнями но не контейнеров.

Возможно, более подходящим является то, что уроки, рассчитанные на обучение, организуются в соответствии с лицензиями. Это означает, что объект курса связан с некоторыми объектами Урока, поэтому курс на самом деле не имеет уроков. У него есть имя, учебный план и т. Д. Уроки, профессора, студенты «привязаны» к курсу, но не являются частью его.

Объект клиента моделирует клиента. Когда клиент покупает некоторые лицензии, он получает право на доступ к курсам, связанным с этой лицензией. Еще раз, у Клиента нет лицензий. Здесь вам нужно смоделировать ассоциации между клиентом и лицензиями. Когда вы это делаете, подумайте, какие детали LIcense зависят от деталей клиента (скорее всего, это не так, поскольку они совсем другие, поэтому достаточно базового (CustomerId, LicenseId)). Конечно, это простые предложения, поскольку я точно не знаю домен.

Главное, что вам нужно углубиться в понимание того, что Клиент, Лицензия и т. Д. Означает для домена и противостоять желанию просматривать вещи «очевидным» способом. Моделирование DDD не сложно, но это очень сложно, потому что вы действительно не должны быть поверхностными.

Answer 2

Вы должны определить агрегаты после бизнес-инвариантов.

Возьмите добычу у Вернона essay on aggregate design.
Для связи разных агрегатов вы можете использовать shared identifiers, что также устранить необходимость в lazy loading.

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