Привет. Подскажите как можно решить такую гипотетическую ситуацию: Есть два контекста/домена

identity и shop. Данных в каждом контексте очень много.
Заказчик говорит, что он хочет чтобы заказы можно было сортировать по логину пользователя. Логины находятся в identity, а заказы в shop.

Правильно я понимаю, что единственный способ решить задачу это мигрировать все логины из identity в shop? Обращаться напрямую у другому контексту не вариант, потому что данных много.

Что вы понимаете под "мигрировать"? Контексты на одной машине

Не совсем понял. Контекст либо изолирован, либо нет. Если для ui выборок я связываю контексты на уровне запросов к бд, то это рушит изоляцию. В identity у меня вооще какой-нибудь redis может стоять или еще что-то с чем я джоин не сделаю

Мб связать не на уровне запросов к бд, а на уровне юз кейса?

Можете пояснить?

Ну конечно, а как ты еще сделаешь. Но зачем тебе здесь контекст идентити )

Ну вот как оказывается, еще джоинить можно. Решение очень быстрое, но, как мне кажется, в перспективе создаст трудности и все равно придется делать то, на чем изначально сэкономили. Контекст идентити занимается штуками связаными с авторизацией/аутентификацей

А, так у тебя одна бд. Ну если с индексами проблем не будет, то лучше джоины, чтобы данные не дублировать.

Ну вот получается сейсчас я должен джоинить и не дублировать, а потом все равно делать eventual consistency, если что-то придется выделять в микросервис или использовать другую бд под контекст

Джоины просто убрать надо будет )

Ну не только убрать, но еще и настроить трансфер данных, который уже мог быть. Хотя щас мне кажется, что мб и не так сложно скейлить такое. В случае использования отдельной бд под контекст, мы же просто делаем бекап основных данных и развертывем на новой бд. Удаляем лишние таблицы, делаем eventual consistency и все. И никаких изменений в коде. Но опять же не знаю как оно на самом деле

Ну колонку с данными надо будет скопировать еще, в общем разница невелика. Но если тебе понадобится отделять сервис, то лучше сразу конечно сделать.

есть еще решение с дубликатом данных. Т.е. если у тебя два домена используют одни и те же данные, то обычно ситуация сводится к тому, что один домен является овнером данных (мутирует их), а другие - потребителями. Самый простой пример - складской учет, который говорит магазину какие товары есть для продажи, а какие кончились на складе магазина. В таком случае, один из возможных вариантов как еще решить проблему общих данных - застримить данные от овнера ко всем потребителям. Т.е. ты из домена передаешь данные необходимые для бизнес логики в других доменах. Т.е. по сути, копируешь два раза данные, только с нужными трансформациями для каждых доменов. Если по реализации - опять же, один из способов это сделать - стриминг, т.е. используя Event-Carried State события, от овнера отдаешь всем потребителям стейт нужный (каждый потребитель сам решает, какие данные и в каком виде они нужны). Это подойдет, если у тебя синк данных может занимать время, есть уже готовый брокер, который может обработать столько данных и система разделяется по бизнес флоу, а не по ресурсам. еще из минусов - придется дублировать данные и могут коллизии возникать. Т.е. данные долго синхронизируются + придется думать о каком-то публичном id, что бы связать данные между подсистемами (при этом, без привязки на реализацию id из базы, так как базы могут быть разными и обычный сиквенс может палки в колеса вставить)

пример со складским учетом некорректный - он не требует дублирования данных. Вот вообще

зависит от того, как на него смотреть. Если воспринимать склад и магазин как разные системы с разным набором пользователей, при этом системы не находятся в одном монолите - придется думать, как данные из одной системы получить в другой

повторюсь - при любом раскладе нет никаких причин дублировать данные. Именно "дублировать"

можешь раскрыть мысль?