Возможно моя проблема в том что я в принципе плохо представляю себе этот процесс

Ну вот ваши a/b выкатки как работают? Выкатили включили или паралельно две версии деплоите?

Ну тоесть это a/b, canary или blue/green?

Выкатили и включили. Это не блю грин

Как включаете

Своя аб-тест система. Выкатываем фичу, включаем на N процентов через интерфейс этой самой системы. На stage и ранее тестирование проходит через мануальную простановку куки эксперимента

Поздравляю, у вас есть фича флаги)

Ну так это у вас и есть фича-флаги.

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

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

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

Для веток все ещё есть неплохой кейс - когда сложные изменения и непонятно как раздробить работу - в этом случае можно сделать ветку наговнять в ней, разобраться что надо сделать и удалить. Скажем 2-3 дня на прототип а потом с полученными знаниями уже планировать нормально работу.

Если форсить этот процесс, если во главу угла ставить обратную совместимость (сделай копию, поправь, переведи на новую реализацию) то можно добиться весьма высокого качества и скорости фидбэка.

Но опять же если вас устраивает то проблемы нет. Просто надо понимать минусы подхода. У фича флагов они есть - чуть более требовательны к декомпозиции и культуре тестирования.

Понял. Ну я просто думал что фича флаги это более сложно чем впиливание эксперимента в фронт и бекенд. Может мы это не так называем просто

Я о том и говорил - фичафлаги это просто конфигурация. Изоляция кода if-ом.

Вы тут про фиче-флаги уже несколько сот сообщений написали. У меня был интересный кейс.

Планировалось интегрироваться с новой Order Management System (OMS), и надо было, чтоб заказы, созданные ранее, продолжали работать со старой системой (инвойсы, доставка, рефанды и т. п.), а заказы, созданные после релиза интеграции - с новой OMS. Тоже сделал флаг с таймстемпом (if-ы в коде на него). На пре-проде приходилось до релиза проверять заказы в будущем и прошлом - зато могли мерджить новый код и выкатывать на прод задолго до релиза интеграции! Так что да, я за фиче-флаги. Только важно понимать, что это не всегда просто конфиг "на всё", иногда надо одновременно старая+новая реализация

ну это уже branch by abstraction паттерн

Правда? Никогда про этот паттерн не читал, но применил, значит)))

ну не совсем, это когда у тебя абстракция появляется которая в зависимости от конфигурации решает какую реализацию юзать - старую или новую.

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

https://www.amazon.com/Continuous-Delivery-Deployment-Automation-Addison-Wesley-ebook/dp/B003YMNVC0
Есть вот такая книжка, там как раз рассматривается добавление нового поведения поверх старого
Правда, в книге придерживаются подхода "каждый коммит - это релиз-кандидат", поэтому и акцент делают на вещах, которые этому подходу соответствуют, но и о других подходах упоминают
Ну и из их подхода некоторые вещи можно спокойно у себя применять
например, по изменению схемы таблиц: поле не дропаем несколько версий, если надо изменить его формат - добавляем новое поле рядом, чтобы старый код продолжал работать со старой схемой, а новый - работал с новой схемой и т.д.

Объясните, пжл, в концепции DDD доменный сервис может зависеть от интерфейса репозитория? Если да, то интерфейс репозитория должен быть объявлен в доменном слое или в инфраструктуре?

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

Спасибо