Возможно, вы захотите отобразить уровень запасов на веб-странице, или вы можете отобразить номер издания инвентаря на складе (представьте, что ваш инвентарь - книги, журналы и т. Д.). Эта информация поступает из домена инвентаризации.
Главное, на что следует обратить внимание, это то, что вы говорите о представлении, то есть о том, что использование устаревших данных допустимо.
При этом вам не нужно взаимодействовать с агрегатами (которые несут ответственность за предотвращение нарушения изменений бизнес-инварианта), а с представлением недавней копии состояния агрегата.
Поэтому я обычно ожидаю, что запрос будет выполнен по каталогу продуктов, а другой - по инвентаризации, и что-то, что объединит их в DTO, которые вам понадобятся для поддержки представления.
Загрузить как домен продукта, так и агрегаты домена инвентаризации?
Так что это близко . Нам не нужно загружать агрегаты, потому что мы не собираемся ничего менять. Но нам нужно их состояние; чтобы мы могли загрузить это. Тем не менее, я обычно ожидаю, что два домена будут работать в разных процессах. Поэтому мы будем звонить обоим, а не загружать оба.
Будете ли вы хранить некоторые свойства в своей сущности домена Product для количества на складе и издания на складе, а затем использовать события домена для обновления их при обновлении сущности Inventory?
«Не пересекать потоки. Это было бы плохо».
Использование событий для координации информации в разных контекстах домена: отличная идея. Вытеснение концепций, принадлежащих одному домену, в другой: противоположность великой идеи, за исключением большей.
Вы хотите сохранить домены в чистоте. Эти приложения , которые взаимодействуют с доменами, это не так важно. Так, например, для приложения Inventory целесообразно вызвать службу в приложении продукта, чтобы запросить некоторые специфические для продукта концепции для добавления в представление. Или наоборот.
Я не знаю ни одной причины, по которой одно приложение должно быть ограничено одним доменом. Пока существует единый источник правды, вы можете распределять транзакции любым удобным вам способом.
Но просто чтобы обдумать это, в приведенном выше примере мы получим потенциально 2 таблицы БД для каталога товаров и инвентаря товаров. Теперь мы используем тот же идентификатор в них, как и тот же продукт.
Это был бы легкий путь. В более широком смысле вы используете один и тот же идентификатор, потому что сущность реального мира одинакова; два разных ограниченных контекста моделируют эту сущность по-разному, но модель не является сущностью реального мира.
Когда это не сработает, тогда вам понадобится какой-то запрос, чтобы восполнить пробел. Я думаю, что наиболее распространенным вариантом этого является то, что более новый объект сохраняет идентификатор более старого объекта. Вы увидите это и в рамках одной БК: заявители, когда они будут одобрены, станут клиентами. Это другой агрегат (состояние, связанное с клиентом, подчиняется инварианту, отличному от состояния кандидата); поэтому, если ваш уровень персистентности использует потоки событий, потоку для нового агрегата потребуется другой идентификатор. Так что где-то будет состояние, в котором говорится, что «этот заявитель стал этим клиентом».
Или мы могли бы использовать 1 таблицу и 1 строку таблицы для данных и просто отобразить соответствующие данные на совокупные свойства?
YIKES! Нет, не делай этого. Вы добавляете конфликт транзакций без какой-либо деловой причины для этого.