Проектирование агрегатов и сущностей
Хочу понять как правильно проектировать агрегаты и разделять ответственность между ними. Предположим есть в понятиях две бизнес терминов две термина Хостинг-аккаунт и Виртуальный хост. По логике вещей это два разных агрегата. НО виртуальный хост не может существовать без хостинг-аккаунта. Удали хостинг-аккаунт и нужно удалить все виртуальные хосты, а кроме этого, от настроек хостинга будет зависеть какие настройки PHP и другие опции могут быть установлены для виртуал-хоста. Очень удобно делать hosting->getVirtuals();
Но в таком случае агрегат Хостинг становится очень большим. Он должен включать в себя целую коллекцию виртуал-хостов. Если все же представлять их как два разных агрегата, то возникает вопрос их связи друг с другом. Получается нужен какой то третий объект-коллекция, через который будет происходить связь хостинга и его виртуал-хостов, ну и работа будет происходить через сервисы каждый раз, что не очень удобно.
Ответы (2 шт):
hosting->getVirtuals() это ООП, но с ним есть проблема, классический ООП плохо подходит для серверной разработки. Фактически DDD добавил в обиход набор практик, решающих эти проблемы. В рамках агрегата должны располагаться сущности, которые обязаны оставаться в консистентном состоянии по отношению друг к другу в любой момент. В вашем случае это могло бы быть требование, чтобы суммарные ресурсы выделенные для хостов не превышали лимит заданный для аккаунта. Если подобных требований нет, то хосты можно размещать в собственном агрегате и доставать через собственный репозиторий передавая в него идентификатор аккаунта как аргумент hostRepository->getVirtuals(accountId)
Изначально я передерживался такой же позиции. Но Есть два фактора, которые меня смутили:
В книге "Чистая архитектура" сказано, что нужно стремиться к небольшим агрегатам. И в этом есть много логики. Особенно если работать с применением Event Source когда объект восстанавливается из событий. Чем больше агрегат тем сложней и дольше его будет восстанавливать.
Если брать в качестве примера тот же хостинг. У хостинг-аккаунта очень много лимитов. Например: количество почтовых ящиков, ФТП аккаунт, виртуал-хосты..... Если все это включить в один агрегат хостинг, агрегат получится ГИГАНТСКИЙ. Больше похоже что это разные агрегаты в одном контексте, которые между собой связаны сервисами. Хостинг может знать про лимиты всех услуг, а сервис будет контролировать, чтоб не было выхода за приделы.
Но я не уверен, что это верная логика. Уверен, что такая проблема есть не только у меня, и вероятно есть какой то стандартный шаблон ее решения.