DDD: поддержание ограничений в агрегатах - PullRequest
1 голос
/ 29 марта 2012

Все еще читаю и изучаю DDD и пытаюсь применить его к проекту, над которым я работаю. Я все еще пытаюсь обойти агрегаты и натолкнулся на интересный вопрос.

Предположим, у меня есть 2 агрегата, один из которых имеет учетную запись для корня, а другой - пользовательскую для корня.

Учетная запись не может быть создана без Пользователя, но Пользователь может, поэтому оба они являются корнем своих Агрегатов. Обратите внимание, что их Агрегаты включают другие объекты, но это не важно для моего вопроса.

Некоторые бизнес-правила: 1) Когда учетная запись создана, она должна быть связана с пользователем. Если Пользователь не существует, его сначала нужно создать.

2) При удалении учетной записи ее соответствующий пользователь также должен быть удален.

3) Когда пользователь создается, его не нужно связывать с учетной записью.

3) Когда пользователь удаляется, если он связан с учетной записью, он также должен быть удален.

Поскольку Учетная запись и Пользователь формируют свои собственные агрегаты, вероятно, там будут свои собственные Репозитории. Это означает, что в каждом из этих репозиториев будут определены стандартные методы Add, Delete, Find и Delete.

Итак, учитывая эти сценарии, как лучше всего выполнить следующее: 1) Когда учетная запись была создана, я решил, что вызову метод для свойства его пользователя, чтобы подтвердить, что он существует. Это правильно?

2) Когда удаляется Учетная запись, как мне также удалить ассоциированного Пользователя. Из хранилища аккаунтов? Но не будет ли это просто дублировать код в репозитории пользователей? Или хранилища могут ссылаться и вызывать друг друга?

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

Я где-то читал, что если логика пересекает две сущности или совокупности, подумайте об использовании службы. Но меня это не устраивает, поскольку, что мешает клиенту (при условии, что API будет развиваться, и пользователю в будущем будут открыты другие презентации), чтобы обойти Сервис и просто вызвать хранилища?

Обновление 1:

Только что понял, что это, вероятно, связанный вопрос: Как я должен навязывать отношения и ограничения между совокупными корнями?

1 Ответ

6 голосов
/ 29 марта 2012

Из книги DDD, стр. 128:

Предполагается, что любое правило, которое охватывает AGGREGATES, не будет постоянно обновляться.Посредством обработки событий, пакетной обработки или других механизмов обновления можно разрешить другие зависимости в течение определенного времени.

Теперь, сначала вам нужно выяснить это для себя, с экспертами по доменам, какие изrules является true инвариантом, что означает - оно должно быть немедленно заключено.Если есть такое правило, оно должно применяться корнем агрегата, и в этом случае вы можете рассмотреть возможность объединения этих двух агрегатов в один.Если такого правила нет, то, как указано выше, возможна согласованность.Вы можете рассмотреть доменные события для этой цели.см. пост Уди Даана

...