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

всмысле. Мне условный UserId надо в каждом контексте сделать и при передаче из одного в другой надо из User/UserId сделать Product/UserId ?

Это уже излишние загоны но в целом да :)

+1

или shared kernel технический

Ну или язык со структурным тайпингом :)

Для одного контекста данные полученные из другого ничем не отличаются от данных полученных от кастомера или сторонней системы. Ты же реквесты / респонсы мапишь на свои структурки?
По хорошему, в контексте ты описываешь интерфейс, например,
getUserInfo(int $id): UserInfo
При этом UserInfo это структурка этого же контекста.
В инфраструктуре своего контекста делаешь адаптер, который маппит ответ какого-то юзер контекста на эту структуру.

Надо ли тебе UserId прямо как VO внутри этой структуры? Зачем? Ну если надо - пишешь свой и в адаптере респонс мапишь на свою внутреннюю VOху

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

Но по моему опыту хватает плоских ДТО, с примитивами в других контекстах

Там есть одна опасность - у тебя вот в сообщении ты общаешь на все данные

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

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

А в целом можно мысленно представить что все контексты - независимые микросервисы и все написаны на разных языках. Просто что бы было проще представить себе весь этот треш

Лучше больше загоняться не по тому на какие объекты ты данные мэпишь когда их между контекста и передаешь а про то какие вообще данные

Все так. Дальше все про выразительность языка и тулов

Этот общий технический шаред кернел во первых начинает пухнуть безбожно, а во вторых становится адской проблемой в ситуациях типа "а вот тут задачка подъехала, но на пхп мы её не решим, нужно брать ноду/го/джавку/етс
И приходится дублировать этот шаред кернел в разные языки, держать из синхронными и вот это вот все

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

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

А разве если делать для каждого контекста отдельную структуру, то это не приходиться делать? В смысле, мол при изменении контракта нужно и маппер/нормалайзер допиливать.

Не делай breaking changes по возможности. Если в респонс добавилось новое поле, но тебе оно не нужно в другом контексте, то и не мапь его.

Ну и чутка магии не помешает. Полно готовых либ которые один объект на другой сами замапят

Если их не делать, то и с синхронизацией в других языках попроще будет. Но, в любом случае, один раз поправить маппер проще, чем править в множестве мест, где ранее "общая" структура использовалась

в целом хорошей идеей будет просто сделать процесс который максимально усложнит шаринг данных_)

тип что бы 10 раз надо было подумать перед тем как в это ввязываться)

это да =)