Я все еще читаю, изучаю DDD и пытаюсь применить его к проекту, над которым я работаю. Я все еще пытаюсь обойти Aggregates и наткнулся на интересный вопрос.
Предположим, у меня есть 2 агрегата, один из которых имеет учетную запись для корня, а другой - пользовательский объект для корня.
Учетная запись не может быть создана без пользователя, но пользователь может, поэтому они оба служат корнем своих собственных агрегатов. Обратите внимание, что их агрегаты включают другие объекты, но это не важно для моего вопроса.
Некоторые бизнес-правила: 1) При создании учетной записи она должна быть связана с пользователем. Если Пользователь не существует, его необходимо сначала создать.
2) При удалении Учетной записи также должен быть удален связанный с ней Пользователь.
3) Когда Пользователь создается, его не нужно связывать с Учетной записью.
3) При удалении пользователя, если он связан с учетной записью, он также должен быть удален.
Поскольку Учетная запись и Пользователь образуют свои собственные агрегаты, вероятно, будут свои собственные репозитории. Это означает, что стандартные методы добавления, удаления, поиска и удаления будут определяться каждым из этих репозиториев.
Итак, учитывая эти сценарии, каков наилучший способ выполнить следующее: 1) Когда создается учетная запись, я решил, что вызову метод для ее свойства пользователя, чтобы проверить наличие пользователя. Это правильно?
2) При удалении учетной записи, как мне также удалить связанного с ней пользователя. Из репоистории аккаунта? Но разве это не просто дублирование кода в пользовательском репозитории? Или репозитории могут ссылаться и вызывать друг друга?
3) Когда пользователь удаляется, как лучше всего определить, связан ли он с учетной записью, и удалить его без дублирования кода (вероятно, аналогично второму вопросу).
Я где-то читал, что если логика пересекает две сущности или агрегаты, подумайте об использовании службы. Но я не удовлетворен этим, поскольку что мешает клиенту (при условии, что API будет развиваться, и пользователь будет использовать другие презентации в будущем) от обхода службы и простого вызова репозиториев?
Обновление 1:
Только что понял, что это, вероятно, связанный вопрос: Как следует Я навязываю отношения и ограничения между совокупными корнями?
