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

Shared Kernel, но это скользкая дорожка

то есть это некий Common контекст, я правильно понимаю?

В чем соль? Чем дорожка помазана, что путь по ней скользкий? Типа в какой то момент получится сильная связаность?

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

Ну я вот для примера могу привести такую ДТО как юр лицо. Оно между контекстами одинаковое. Где ж его хранить?

любое решение превратится в помойку если с ним работать на отъебись

а почему это разные контексты, если работают с одним объектом?

нашел опенсорс, который может по openapi генерить такую красоту

Это страховка. Есть КАСКО а есть ОСАГО. Внутри все отличается. Но Юр лица и там и там одинаковые

ну я конечно хз, без изучения домена мало что можно сказать. Но раз ты говоришь, что это ДТО, то видать данные для него получаются из запросом в другой контекст. А раз так (и при этом каско и осаго живут в разных контекстах тоже), то каждый контекст должен у себя завести интерфейс для получения ДТОхи и свою ДТОху

Но в теории, так как это всего лишь ДТО без поведения, то да, интерфейс этот можно вынести в шаред кернел и ДТОху результат возле него положить. Но потом появится третий контекст, которому надо тоже юрлицо, но еще с какойто доп инфой и начнется костылирование

ну я пока смотрел такой вариант, что я делаю Common контекст, и в него ложу абстрактные классы. А дальше уже если кому то будет нужно он их наследует и расширит. Я понимаю что весь этот Common это путь в свалку. Но в тоже время кажется не правильным копипастить одно и тоже между контекстами.

хотя что плохого в копипасте? больше кода, но типа low coupling

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

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

я конечно не сильна в ддд, но мне кажется правильным, чтобы контекст А (Common) работал с контекстом В и контекстом С, при этом В и С  отдельные, ни с чем и ни чем не связанные, так ты и сможешь переносить их  в другую инфраструктуру

напоминает Yii2

про это уже выше сказали. Весь этот Common будет разрастаться так что начнет себе включать вещи, которые нужны и B и С и D и E. И когда ты будешь из B это все доставать, то тебе не нужны все эти штуки которые есть для D и E.

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

если у тебя Common начинает разрастаться, то это также повод его разделить

Ну вот это и есть скользкий путь. Если бы Common не было вообще, а все оставалось бы внутри B, C, D, E то и не надо было бы разделять весь этот Common