#domain-driven-design #cqrs #event-sourcing
#дизайн, управляемый доменом #cqrs #источник событий
Вопрос:
Я новичок в ddd / cqrs / поиске событий, и у меня есть некоторые концептуальные проблемы.
Например, я хочу реализовать простую корзину покупок, и она должна иметь ограниченный контекст: администратор и веб-сайт. Оба будут обращаться к одному и тому же aggregate: order.
В этом случае могу ли я предоставить общий доступ к агрегированным данным с перекрестными ограничениями контекста? Если нет, то как я могу это сделать в приведенном выше примере?
Приветствую, Рон
Комментарии:
1. Какие сценарии приводят к этому? Пользователь может разместить заказ на веб-сайте, но что администратор может с этим сделать? Рассматривали ли вы возможность того, что
Ordersэто BC сам по себе?2. Администратор может утвердить заказ, вернуть заказ и так далее… Да, order может быть BC сам по себе, это хорошая идея.
Ответ №1:
Вы можете использовать общее ядро, если вам необходимо совместно использовать части модели между двумя или более ограниченными контекстами. С учетом сказанного, стоит задаться вопросом, являются ли значение, структура и поведение порядка в обоих этих контекстах абсолютно одинаковыми. Если нет, вам было бы лучше поддерживать их в обоих ограниченных контекстах.
Ответ №2:
Совокупный корень принадлежит только одному ограниченному контексту. Вы можете взаимодействовать с этим агрегатом из другого BC, используя опубликованный язык (контракты / команды). Что вам нужно, так это нарисовать свою контекстную карту и решить, какой BC находится выше по потоку, а какой ниже по течению. Это действительно важно.
Проверьте эту статью => http://www.infoq.com/articles/ddd-contextmapping