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

Это не самый худший вариант. Иногда уже не понятно, что, почему и для чего налеплено. Единственный выход - релиз в квартал и регрессионное тестирование всего функционала. Вот многие узнают сейчас)

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

На это и расчёт обычно. На самом деле иногда годами

Был у нас один проект, на который бизнес жаловался “а чего так долго-дорого, пойди архитектор, разберись там”.
Я провел аудит, сделал отчет с разбором причин и пакетом рекомендаций.
Первый результат: PO уволился через несколько дней

Знакомая ситуация.

Кстати есть и такой кейс.
Договариваемся мы об интеграции с неким партнеров, у которого “тяжелые” процессы.
Делаем интеграцию, запускаем в пром. Все работет.
Потом партнер приходит с запросом сделать что-то еще, и это другая функциональность.
Предлаегаем сделать отдельную интеграцию.
Отвечают “да вы что, у нас же это месяцы и месяцы разработки! вот у нас уже работает шлюз, давайте немножно вот тут допилим….”
вот так начинается монолит, с нарушения Sepraration of Concerns, смешения двух задач в одной функции.
И бизнес уговаривает: ну такой важный партнер, ну давайте прогнемся, такие ж деньги уйдут мимо…

В итоге мы пришли к модели отдельно стоящего сервиса-шлюза-адаптера между партнером и нашими внутренними процессами.
Накостылить в шлюзе можно что угодно,
но оно не угрожает устойчивости платежной системы

Да, Separation of Conserns, ключевой принцип. Жертвовать им нельзя.

Да, ACL это даже внутри полезно, между разными подсистемами. А уж шлюзы точно все отдельными и независимыми должны быть. Даже со своей БД...

Коллеги, появилась необходимость соответствовать ФЗ хранении данных пользователей на территории РФ. Также есть ряд других стран, где есть похожие требования. Делать отдельные развёртывания не хочется, но в целом система позволила бы.  (Мы b2b)
Но, появился вариант, с реализацией SSO на базе OpenID, где провайдеры будут являться страной, и данные пользователей можно было бы хранить в оригинале там.  
Есть у кого-то опыт решения подобных проблем, не могли бы поделиться? Что на счёт такого варианта?

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

Но для России пришлось публиковать и отдельное приложение мобильное

Бедный по, который все делал по технической моде. И чаще всего в технике вообще не разбирающийся.
Технари золотые говнокодят, а почему по должен отвечать?

Вот это хотелось бы избежать. Насколько нормален кейс с автоматическим определением провайдера, скажем по логину?
Схема примерно такая: пользователь вводит логин, после чего сервер определяет при помощи какого провайдера зарегистрирован пользователь и отдает ссылку на конкретного провайдера.

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

Тут вот Uptime Institute выложили материал связаный со словом на букву К. Мне кажется понравится коллегам, интересующимся непрерывностью бизнеса.

Да, я хотел делать это на стороне клиента. Идентификация по логину происходит на головном сервере, после чего сервер возвращает конкретный OIDC, а клиент аутентифицируется уже на нем.

@gtkuler По опыту, не нужно пытаться реализовать букву закона на 100%. Нужно взаимодействовать с органами по аттестации и совместно выработать решение, которое следует духу закона. Мелочи типа "мы обрабатываем IP-адрес при входе, а это формально тоже ПДн" обычно никого не волнуют. Если подходить строго формально, то никто не соответствует - так написаны законы.

Тут уже наши юристы настаивают на хранении данных на территории страны пользователя 🤷‍♂️