Ты о чём-то типа конфирма в реббите ?

да, про него

но на самом деле я не шарю, ток читал про такое

А, тогда понял :)

Ну это один из способов гарантии доставки в сам брокер, да. В сочетании с тем же аутбоксом это гарантирует, что ивент уйдёт в брокер

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

Я это дело немного по другому понимаю чем @fes0r .
Да оно синхронно и по АПИ. Но связи нет между контрастами. Как говорит уди главная проблема людей что они думают что сервис = единица деплоя. Хотя это сервис это логическая штука с главным признаком что контракты между сервисами маленькие(мы же задаём только один публичный контракт в виде интерфейса). Там получается что часть сервиса в котором день рождения инжектируется как  Dependency injection(только на уровне всех сервисов а не уровне одного) внутрь приложения прайсов(но не сервис прайсов).  И общение идёт внутри логического сервиса дня рождения по айпи или оно там сразу в базу данных ходить не важно. Публичного апи и контракта не появляется. Ибо это всё утилизируется и используется самим же сервисом.
А насчёт отвалилось если что то. Ну опять же спрашиваете бизнес игнорировать ответ в таком случае или стопать процесс.
В случае цены я бы предположил что мы вызвали асинхронно несколько реализаций интерфейса расчета (при чем мы не знаем что в них)  и просто игнорируем те что по таймауту не зарезолвились.

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

Спасибо :)
В общем это должно работать по DIP принципу? Интерфейс "Модификатор цены" лежит на уровне контекста "расчет цены", а реализации лежат в других контекстах. При этом они не отдают данные, а отдают решения по входным параметрам и на основе своих данных.  Правильно я понял?
Просто получается, что так или иначе "контекст рассчета" цен должен знать кого ему вызывать поэтим интерфейсам, и что-то это уже не DIP. Да и смысл самой абстракции "интерфейс" теряется. Или тут абстракция и не нужна, а под интерфейсом понимается - публичное апи?

Я так понимаю  все таки синхронно/асинхронно - вопрос второстепенный больше и по задаче конкретной. Потому что, как, например, сгенерить цену сдесь и сейчас на странице - асинхронно?

На сколько я понял наши понимания принципа совпадают.
Почему интерфейс теряется? И дип? Сеовис цен не должен ничего знать.
Представьте что все реализации просто в одну папку складываются. И при расчёте из нее берутся все реализации и запускаются. И тому кто запускает пофигу сколько тех реализаций и что внутри. Ему важно только чтобы они удовлетворяли интерфейсу.

Это называется service provider interface (sip)

Ну если брать пример про цену, то модификаторы могут комбинироваться с собой. Типа "Если скидка за ДР (контекст профайла) уже есть, то скидка за количество заказов (Контекст заказов) - не применяется". И я думаю это не редкий кейс. Хотя данные можно прятать за абстракцию. Т.е. контекст не знает о других контекстах, но знает о возможной структуре данных.

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

Понятно, спасибо :)

Аймнот инглиш, бот не бань 😂

Какой контракт нужен для репозитория если нарушен FK constraint при записи в таблицу? вернуть ошибку referential-integrity-violation?
у меня есть сущность внутри которой лежит id другой, получается, появляется последовательность сохранения двух новых сущностей? это норм или не так должно работать?

а так ли нужен fk там... ну то есть, может убрать его?

что до контрактов - "таки как договоритесь и что надо клиентскому коду так и будет"

С fk проще гарантировать консистентность

я просто не удаляю штуки) так что для меня "не проще"

ну короч, вопрос был "какой контракт когда ФК" - контракт выбирается по тому как обе стороны которые по этому контракту работают взаимодействют и договариваются

"в каком порядке" это тоже часть контракта и это усложнение оного. Либо контракт это форсит явно и сложно нарушить либо "что удобнее - фк или без фк"