Микросервисы без архитектуры Независимых и автономных микросервисов - прям мало. В основном слышу от людей на местах, что разделили как пришлось (да и вижу часто), куча зависимостей, сложность только выросла, а t2m стал только выше. При этом многие команды делают ставку на нейросети, чтобы ускорить разработку, а когда две команды пилят два разных сервиса, которые друг от друга зависят на уровне бизнес-логики, критических правил (блокирующией зависимости), - компании вообще не получают выгоды, - что толку, что ты можешь написать код теперь не за две недели, а за час, если потом все равно две недели ждешь другую команду, пока они свое доделают. Узкое место переехало, но не исчезло. Что тут делать? Ответ скучный, но честный: учить архитектуру. Не паттерны ради паттернов (что на самом деле лучше, чем ничего). Как минимум – как правильно выделять границы, как думать о связности (coupling) и сцеплении (cohesion), как отличить организационную зависимость от технической. Микросервисы – мощный инструмент, но только когда граница сервиса совпадает с границей домена и границей команды. Все остальное – это просто усложнение ради усложнения. Что прямо противоречит самой идее архитектуры – управлять сложностью и сдерживать ее рост. В общем, изучайте архитектуру 🙂