Приветствую ) Вопросик: Пытаемся развязать между собой сущности с помощью

общения через Id а не связи и подконтесты/контексты. В базе нет FK. Плюс Модули разных контекстов не должны знать друг о друге. Ну в общем как тут рассказывают и в книжках :)
Как архитектурно реализовать минимальную целостность ids? Т.е. проверить наличие сущности в другом контексте.
Делать какой-то Common/Gateways и в нем интерфейс с exist методом ?

Логическая

так то понятно, что без референсов хочешь, но если тебе нужен будет join какой нить, то по чем будет поиск в бд?

А как join зависит от FK?

ну так сделай их FK, или у тебя нет уникальности их?

Делая FK я связываю базу сильно.

странно...

Ну смотри, есть два контекста например. Ведут рахные разрабы их. При FK есть зависимость их работы. Должны быть созданы таблицы,заведены данные. Сложности одни. + FK лишняя нагрузка на базу.

повышать достоверность входящих айдишников, понижать возможность прихода ошибочного айдишника в даунстрим сервисе. Сделать все, чтобы если пришел новый айдишник, то он 100% есть. Так же можно предусмотреть компенсационные действия если апстрим сервис отрапортует об ошибочности ранее высланного айди

Это понятно , я банально могу сходить в другой сервис, репу и т.д. Как сделать это красиво :)

зачем тебе ходить? если у тебя есть айди, значит он существует в соседнем сервисе, иначе сделать так, чтобы айдишника у тебя не было в случае ошибки/удаления

а зачем тебе метод exists? в какой момент ты его хочешь вызывать?

Прилетел с формы, хрен знает что за id

В каком нить бизнес процессе, или в контроллере прям

а как так получается что у тебя raw данные, которые тебе не принадлежат приходят и тебе нужно делать ассампшоны насчет этих данных?

Сложно написано... не все понял. Прилетели данные с фронта. Фронт ошибся, или кто то спамит невалидными данными

вот чтобы ни абы какой, то приведи id к vo, и читаемость улучшит, ну и кое как будет фильтровать

У меня есть VO

в целевом модуле ничего не делаешь и ничего не вызываешь, сначала пропускаешь данные с фронта через тот модуль, который может подтвердить или опровергнуть данные.

Этот вариант нравится вполне :) Поэтому совета и просил)

+FK лишняя нагрузка на базу? 🥺 а чем отличается нагрузка на бд FK от обычного кей?

То что проверка целостности и дедлоки

проверка целостности чего? Дедлоки? у тебя что там, конкурентные запросы?

Целостости что FK есть в другой таблице, каждый раз чекать. Дедлоки - к слову сказал, но проблема такая у FK есть

мне кажется тебе надо больше задумыватьяс когда ты что то делаешь, а не просто делать потому что где то написано, как с этитим фк, ты удалил FK, что бы "развязать модули" и сразу решил добавить Gateway с методом exits что бы их быстреньке связать назад только уже своими костылями

так, погоди.. FK - это .... ?

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

Например мы с напарником сейчас пилим паралельно сущности, у них есть связи (логичские через id). Без ФК мы не ждем друг друга и прекрасно справляемся :) С ФК было бы сложнее.

А зачем это проверять? Ну добавишь ты проверку на existing. А потом эта сущность пропадет из другого контекста. И что тогда

и все таки если связи в одном модуле (контектсе), не вижу ничего плохого в fk, ты больше получишь оверхеда, чем профита от 'развязал сущности'

Это уже другой вопрос. Некоторые вещи softdelete, некоторые удалять ивентами и как то уже решать по бизнесу. Для чего: 1) чтобы прям откровенный шлак не лежал 2) фронт был консистентный а не проверял везде на null

Соглашусь, не везде убираем FK.

Может эти две модели должны быть вместе тогда?

Фронт может быть абсолютно любой

Так а что плохого случится если не будет айди в другом контексте или целостности? Весь прикол изготовления от связей fk или ссылочных это в том что пофиг есть в данном месте или нет. За это отвечает тот процесс которому надо обе эти штуки и знает что делать если они есть или нету.

Ну пример - кривой фронт. Или нарушится какой-либо процес, и это надо компенсировать.

Исправить фронт? Или процесс? И все. Ну и а что меняется если кривой fk также надо компенсировать. Обсолютно тоже самое вроде

согласен, всегда есть корень, который ссылается на другую сущность, в редких кейсах требуется ссылаться и в обратную сторону

Не понял но ладно. Вообще айди это обычно всё что обьедняет. Корень это про агрегаты. А не про независимые процессы.

Как исправить фронт ? Вот допустим есть связь. Я присылаю какую нить структуру json фронту, ну не знаю order а в нем профиль заказчика краткий. По какой то причине там лежит некорректный userId в БД у order. Выходит я пришлю пустого юзера. Фронту надо это тоже как то обрабатывать, мне как то обрабатыват чтобы сделать nullable, зачем?

Так джоин в этом случае просто ничего не вернёт и всё

Да, но мне надо сделать обработку чтобы прислать или null или profile и тоже самое сделать фронту. Вопрос зачем?

Разве у VO могут быть id?

большинство понимает это как vo, я же это называю 'приведение к типу'

сори, ваш ответ в контексте корректный, а вопрос на который вы отвечали — нет у меня произошел мисматч ответа и вопроса

Ну да. Если отдельно взять вопрос и ответ, то фигня какая-то)