Привет, я увидел ваш пост и подумал, что могу дать вам свое мнение.Во-первых, я должен сказать, что я работаю над проектом в течение трех лет, поэтому я не эксперт.Но в настоящее время я работаю над проектом в качестве архитектора, который занимается коучингом разработчиков в DDD, и я должен сказать, что это не прогулка в парке ... Я не знаю, сколько раз я рефакторинг модели и Entityотношения.
Но мой опыт показывает, что у вас есть несколько хранилищ (больше, но не много).Мои Агрегаты обычно содержат несколько классов, и граф объектов Агрегат не такой глубокий (если вы понимаете, о чем я).
Но я стараюсь быть конкретным:
1) Совокупные корни определяются вашими потребностями.Я имею в виду, если вам кажется, что вам нужен объект Tasks через журнал часто, то, возможно, это признак того, что он должен быть обновлен как объединенный корень.
2) Но все не может быть совокупными корнями, поэтому попробуйте капсулироватьобъект, который тесно связан.Заметки выглядят как кандидат на владение корневым объектом.Вы, вероятно, всегда относите Notes к корню, иначе он теряет свой контекст.Примечания не могут жить сами по себе.
3) Помните, что агрегаты используются для разделения больших сложных доменов на более мелкие "островки", которые заботятся о своих обитателях.Важно не делать свой домен более сложным, чем он есть.
4) Вы не знаете, как выглядит ваша модель, пока не достигли большой стадии реализации проекта.Если вы понимаете, что некоторые репозитории используются не так часто, они могут быть кандидатами на слияние с другим корневым объектом (если они имеют такие отношения).Вы можете выделить объекты, которые так часто используются через корневой объект без его контекста.Я имею в виду, например, если журнал является совокупным корнем и содержит заметки и задачи.Через некоторое время ваша модель растет, и, возможно, у Задач появляются ассоциации с Action и ActionHistory, а также с User и Rule and Permission.Теперь я просто выбрасываю кучу общих объектов в функциональности прав / действий / пользователей.Возможно, это приводит к случаям использования, которые подходят к Задачам с другой стороны, «Просмотреть все Задачи, выполняемые этим Пользователем» и т. Д. Задачи все больше вовлечены в какой-либо механизм состояний / рабочих процессов и, следовательно, являются кандидатами на то, чтобы быть самим совокупным корнем.
Окей.Не лучший пример, но он может дать вам идею.Корневой объект может содержать дочерние объекты, где некоторые из его дочерних элементов также могут быть корневыми объектами, потому что он нам нужен в другом контексте (кроме журнала).Но я сам бился головой об стену каждый раз, когда ты запускаешь новую модель.Просто плывите по течению и дайте модели развиваться через своих клиентов / подписчиков.Вы уточняете модель с помощью ее использования.Сервисы (сервисы приложений, а не доменные сервисы), конечно, расширяются с помощью методов, которые отвечают на пользовательский интерфейс и варианты использования (часто один к одному).
Надеюсь, я каким-то образом помог вам ... или нет: D