Страховка. Каско и Осаго. Разные флоу, но ДТО одинаковое

Так мы про домен сейчас говорим или про дто?

Ну я предметную область озвучил для Сергея Милимко. Мы говорим про общие ДТО между разными контекстами

Зависит от инструментов, которые вы для транспорта используете. grpc, graphql, avro предлагают разные способы описания структур, которые ходят между сервисами и кодогенерацию под разные языки предлагают. Это всё-таки не совсем про домен

Ну речь про контекст больше. Вот есть два контекста, осаго и каско. И есть ДТО юр лица которое одинаковое и там и там. И есть два пути:
1) делаем Shared Kernel
2) в каждом контексте делаем свое ДТО, т.е два одинаковых класса.

Вроде бы как плюсы и минусы понятны. Но что скажут знатоки?

Осаго и Каско - это какие-то бренды, а не контексты

эмммм. Почему? То есть есть домен страховка. В нем есть два разных флоу работы с Осаго и работы с Каско.

Ну вот вы сами и ответили - это просто разные флоу работы. Почему вы называете это контекстами?

Если у вас добавляется ещё 3 флоу - это просто ещё 3 стратегии работы. Зачем называть каждую отдельную стратегию - bounded context?

потому что внутри все отличается. Есть понятия свои, которые ограничены контекстом. Под флоу я понимаю путь от расчета до получения документов. Добавьте сюда всякие агенсткие вещи, франшизы и т.п. всякие бизнес сущности.

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

все правильно, у меня также они могут взаимодействовать где то еще между собой. Как пример, человек может оформить КАСКО совместо с ОСАГО.

То есть есть к примеру покупка автомобиля. И там сразу с покупкой происходит оформление каско и осаго.

В общем отвечая на ваш вопрос “что делают с общими классами для нескольких контекстов?” - или дублируют или выносят в отдельный контекст. Зависит от того как это может расширяться

+++ Ну так примерно и обозначил. Понял что универсального решения нет, надо смотреть как это будет расширяться.

зачем разным контекстам одинаковые данные?
Весь смысл в изоляции данных
Кто в итоге будет источником правды для них?
Зачем вам хранить их в 4 разных местах

Ну я выше обозначил же что и там и там есть такое понятие как Юр лицо. И данные для юр лица одинаковые и там и там. И с одной стороны есть shared kernel а с другой стороны дублирование кода. Поэтому и возник вопрос. Ну очевидно что лучше сделать два одинаковых класса в разных контекстах, чем следить за тем что этот shared kernel не превратился в помойку

https://youtu.be/655zq4Sdu2w?t=2520
Insurance example

В какиз бизнес инвариантах используются данные юрлица
и почему они везде используются
Обычно надо оисходить из того что данные надо изолировать а не разделять просто потому что.

У меня ощущуние что эти юрлица вам для отображаения нужны. И что разделили вы просто потому что без анализа полиси  и транзакционной целостности

Спс, сейчас гляну