Задать вопрос
@AlpineMilk

Ограниченные контексты и связи между агрегатами?

начал изучать DDD и у меня возник вопрос о связях между сущностями и ограниченными контекстами. Для примера использую Блог. Пока что я выделил 2 контекста: Пользователь, Блог. Часть лишних полей здесь не учитываем. В контексте пользователь существует агрегат
"User": {
    "id": 1,
    "email": "admin@gmail.com",
    "password": "hashed-password",
    "roles": ["ROLE_USER", "ROLE_ADMIN"],
}

В контексте Blog будет агрегат
"Article": {
    "id": 1,
    "name": "first",
    "content": "some content",
    "author": 1
}

И следуя из полученной мною информации, в контексте блог должна присутствовать своя сущность с Автором так как User находится в другом контексте и имеет свою роль в этом, например логин в систему со своими правами, он может быть как зарегистрированным пользователем к доступу в админ панель так и обычным без особых прав который может например читать статьи, оставлять комментарии и т.д. Допустим агрегат Author содержит в себе связь с id залогиненого пользователя и списком статей которые он создал
"Author": {
    "id": 1,
    "user_id": 1,
    "name": "some name",
    "email": "some email",
    "articles": [1,2,3,4]
}

С учетом того что статья может иметь комментарии, а они в свою очередь имеют "автора комментария" то агрегат статьи будет изменен к следующей структуре:
"Article": {
    "id": 1,
    "name": "first",
    "content": "some content",
    "author": 1,
    "comments": [{
        "id": 1,
        "content": "some content",
        "article_id": 1,
        "author_id": 2
    }]
}

И вот тут возникает вопрос: при текущей структуре к комментариям я приписываю автора, но по сути я не могу так сделать так как автор комментария и автор статьи это не одно и то же и обладают абсолютно разными возможностями. Каким образом можно описать автора комментария? Если создавать сущность для "автора комментария", то получается довольно-таки много сущностей "пользователь", либо можно приписать агрегат User к комментариям, но тогда, если Автор данной статьи оставляет комментарий то, выходит немного путаница. Другой случай: а что если потребуется достать все комментарии который оставил данный пользователь, агрегат User не имеет связей с комментариями, тогда каким образом стоит их доставать для представления? Третье: правильно ли вообще создавать отдельную сущность для автора в другом контексте и приписывать туда id пользователь? И четвертое: с тем что у меня получилось Author это агрегат, который имеет в себе коллекцию агрегатов Article, уместно ли такое решение? Или стоит приписывать туда только id статей?
  • Вопрос задан
  • 124 просмотра
Подписаться 1 Средний Комментировать
Пригласить эксперта
Ответы на вопрос 1
@willrock
Частично присоединяюсь к комментарии выше о том, что вполне себе уместно создать сущность Commentator и какие-либо. Да, можно на парится и везде использовать userId, но тогда как получать список прав? Клонировать сущность User в контекст Статей? Но там может быть много "лишних" полей, вроде флага о двухфакторной авторизации, список привязанных аккаунтов из соц.сетей и прочее. Смысл DDD как раз в том, чтобы контекст Статей ничего этого лишнего и не знал, в том числе для упрощения модели.
Для простоты можно в контексте Статьи сделать "клона" User, в которой будут только необходимые поля для функционирования контекста Статьи.

> И четвертое: с тем что у меня получилось Author это агрегат, который имеет в себе коллекцию агрегатов Article, уместно ли такое решение?

Как будто бы не очень уместное, ведь в таком случае все сущности Article давнного автора будут доступны _только_ через агругат Author, что, пожалуй не очень удобно. Да и агрегат Author получится слишком тяжёлый, ведь для того, что бы тупо обновить имя автора нуобходимо будет всего автора, все его статьи и вообще всю информацию выгрузить в агрегат. Можно, но не рационально.
В "большой красной книге" Вернон как раз приводит аналогичный пример с сущностью Спринг и Таска для домена Скрам.
Если же мы просто будем хранить ссылки на статьи, тогда система получится более удобной. Но тут есть известный trade-off между полностой модили, чистотой модели и производительностью. Можно почитать вот тут на эту тему https://enterprisecraftsmanship.com/posts/domain-m...
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Похожие вопросы