Тип положение объекта в пространстве?

Ну да, ecs тоже используют. Это более менее правильно.

А ооп фп или процедурщина - принципы все эти работают одинаково

Ну, тут такая штука. Я композицией внутри тела, храню его shape. Понятно, что хранить полиморфный шейп - не выгодно, так как для разного shape и физика и рисовка идет по разному. Тогда, есть два пути. Либо мы храним какой то конкретный shape внутри объекта и реализуем интерфейсы рисования и столкновений внутри этого объекта, обсчитывая интерфейсы относительно извесного shape. Либо мы делаем полиморфные объекты для физики и рисования, которые в свою очередь могут быть или прямоугольником или круго или еще чем то и уже их композируем внутри объекта. Но ведь в этом случае, у объекта где мы это композируем все равно должны быть методы для рисования(дернет мнтоды рисования внутри полиморфных данных рисования), физики(дернет методы внутри данных) и так далее.

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

Приветствую. Подскажите плиз с разделение на контексты и ID.
1) Правильно ли я понимаю, если мы используем ID из другого контекста, то нужно создать свой объект ID внутри нашего контекста, чтобы не тащить объект из другого, повышя этим каплинг?
2) Как более правильно проверить наличие объекта другого контекста по ID? Ведь если мы подтянем репозиторий другого контекста - это снова связываем код.
Выходит нужно где то в контроллере/Гейтвее вызывать сначала один контест чтобы проверить валидность ID, а потом другой - чтобы уже сохранить ID ?

1) Да
2) Да

Спасибо!

1) it depends - если весь проект на одном ЯП можно сделать отдельный модуль) это может быть удобным. Но в целом это не столь принципиально. Принципиально не шарить сложные структуры данных между контекстами - ограничивать все оч простыми структурками.
2) контексты должны предоставлять интерфейс который позволяет тебе взаимодействовать с вещами. В целом если у тебя одна операция в одном контексте зависит от того есть ли что-то в другом контексте - воспринимай это как признак неправильно выбранных границ контекстов. Мол отсутствие или наличие чего-то это в целом тоже стэйт. Сходу не могу придумать кейс когда такое допустимо в целом, но у меня там ивенты и все такое между контекстами и потому возможно без всего этого в этом будет смысл. В любом случае надо быть очень осторожным с такого рода зависимостями.

Спасибо!
2) Ну банальный кейс - форма заказа и в ней же форма доставки (или 2 экрана по очереди и 2 запроса). По идее доставка и заказ - это разные контексты.  Надо же как то провалидировать, что ИД заказа в доставке валидный и нам фигню шлют "хацкеры". Зачем нам в БД доставка с несуществующим заказом. Банально потом проверять на риде придется собирая всё в одну кучу.

Нуууу... вот честно я бы забил. Можно чуть усложнить жизнь хацкерам и привязывать order id который генерится на клиенте к сессии пользователя или еще чего... Но в целом - это как раз то ради чего мы дробили. Пусть будет мусор в базе - ничего страшного.

в целом есть способы в таких системах делать referencial integrity

Вполне возможно что заказ будет как бы "размазан" по всем контекстам.
Каждый контекст владеет той частью информации, которая ему нужна.
А самой сущности заказа может и не быть, либо принадлежать какому-то одному контексту, мб sales там

вообще надо опасаться "больших сущностей" (заказ, продукт, юзер) и "контекстов по сущностям". Обычно такие "большие" штуки имеют разные значения в разных контекстах. Где-то продукт это выставлено на продажу, где-то это продукт это штука которую заказал юзер. И ведут они себя чуть по разному.

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

Да что значит он не валидный? Ну есть у нас в одном контексте этот айдишник, оно же со стороны бизнеса ничего не значит, до тех пор пока оплата не пройдет, а она не пройдет

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

Да это и пытаюсь сделать. Но выходит что мы теряем FK + много ID блудают по контестам, которые никак не проверяютя на согласованность между контекстами. и как бы валидность теряется чтоли, как мне кажется. Наверное только кажется.  

Я боюсь того что мне не понятно - раньше у меня была целостная БД и FK. ID я проверял через select или constraint  - а теперь ен понятно, да и вообще не понятно - нужно ли.

Считай как тебе в контору закинули накладную без оплаты. Ну ок, пусть валяется, делов то

А например доставка с ID заказа которого нет вообще и таких 100 ?