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

Ну вот тебе из практики: термин "микросервисы" внезапно прилип к проекту по разработке бэкэнда для маркетплейса. И теперь в конторе полная путаница - для архитектора микросервисы это архитектурный стиль проектирования, а для всяких менеждеров от IT - это конкретный проект, на который есть бюджет, продукт-овнер итд.

OMG!

Получился обратный эффект!

И...? А как надо было бы?

и именно потому, что архитекторы этого проекта троллили "микросервисами" неподготовленных it-менеджеров

Давай начнем с начала — в вашем случае оно надо, чтобы под микро-сервисами понимали целый домен методов и теник, а не просто лепили как ярлык куда удобно?

Как архитектору мне надо именно это.

Зачем? /я не тролю/

Делай просто свое дело :)

А люди пусть словами играют.

А ярлык прилип уже намертво, и как внедрить в сознание теперь правильное понимание термина?

вот я и предпочитаю теперь говорить "сервисы"...потому что "микросервисы" уже занято :)

Сначала нужно было провести разъяснительую работу среди целевой аудитории и найти для них ключевые характеритстики нового подхода, который отделяет его от старых — для разнцых аудиторий аргументы должны были быть разными. А тебе как архитектуру (хотя имхо это задача не архитектора, а манагера, отвечающего за внедрение этой архитектуры и процессов вокруг нее) нужно было бы поддерживать весь домен в целом, чтобы мирить одних с другми. Тогда бы в головах у разных людей остались бы разные характеристики (ну прям как сейчас), но зато все понимали бы (и ты им бы напоминал как ответственное лицо за эту тему), что они часть целого.

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

Если хорошо понимать "зачем" и "почему выгодно", то проще будет обосновать затраты на внедрение изменений.

да-да, в теории всё так, ты прав. но реальность такова, что новые идеи и подходы затаскивают все кому не лень, начиная от вендоров и заканчивая HQ.  Вот и получатеся, что "кто первый встал-того и тапки" :)

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

Не боитесь, что не взлетит или взлетит, но лететь будет низенько низенько? Ведь на первый (грубый) взгляд архитектура микро-сервисов приводит к сложностям — много "странных" компонент, запутанные связи, не поймешь кто их оркестрирует — больше гемора для архитектура и команды поддержки. Хотя разработчики справятся я уверен, им не привыкать лапше-кодить :)

Эта архитектура оправдана, когда нужно много параллельных изменений вносить во все места. Это профит. Но кто сказал, что это реально нужно? Это стоит $$$$$ на поддержку или изменение характера этой самой поддержки (DevOps?).