Закон Конвея на практике или как структура компании отражается на архитектуре софта

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

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