Перейти к содержимому
    Оглавление · Тема 2

    Обновлено: 13 августа 2026 г. в 00:00

    Закон Конвея

    hard

    Как структура коммуникаций формирует архитектуру, и как применять Inverse Conway Maneuver.

    Источник

    Закон Конвея и почему он имеет значение

    Фрагмент обзора Team Topologies: как коммуникации формируют архитектуру.

    Перейти на сайт

    Закон Конвея напоминает простую, но неприятную вещь: архитектура системы повторяет структуру коммуникаций внутри организации. Если коммуникации устроены неудачно, в коде это проявится как высокий coupling, общие «бутылочные горлышки» и зависимость команд друг от друга.

    Суть закона Конвея

    Организация «проектирует» системы, копируя собственные каналы общения. Это работает как в плюс, так и в минус: удачная структура помогает ускорить поток, а неудачная закрепляет архитектурные проблемы.

    Главная мысль

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

    Пример: централизованный DBA

    В обзоре приводится пример: четыре продуктовые команды имеют своих фронтендеров и бэкендеров, но все базы данных обслуживает единый DBA.

    Числа Донбара

    Централизованный DBAЧетыре команды с фронтендом и бэкендом сходятся в общий DBA, который обслуживает общую базу и передаёт изменения в Ops.Frontend DevBackend DevDBAOpsTeam ATeam BTeam CTeam D

    Такая схема естественно ведёт к слоенной архитектуре.

    • Отдельные UI‑слои для каждой команды.
    • Отдельные прикладные сервисы, «собранные» по командам.
    • Общая база данных как единая точка координации.
    Архитектура с общей Core DBКаждый продукт имеет UI и сервисный слой, которые сходятся в общую Core DB с последующим контуром Ops.App AApp BApp CApp DUIApp TierCore DBOps

    Результат — высокий coupling, сложная эволюция и постоянные зависимости между командами.

    Inverse Conway Maneuver

    Обратный манёвр Конвея предлагает начать с желаемой архитектуры и уже под неё перестроить команды. Если цель — независимые сервисы без общей базы, то и структура команд должна отражать эту автономность. В примере выше мы могли бы применить это следующим образом. У нас была бы целевая архитектура с независимыми сервисами с подходом "shared nothing"

    Shared nothing архитектураКаждый сервис имеет собственные клиентский слой, API и хранилище данных, без общей базы.Service AService BService CService DClientAPIData Store

    И для такой архитектуры нам нужна следующая структура команд

    Структура команд под shared nothingКаждая команда включает клиент, API и базу данных, отвечая за свой сервис end-to-end.Client DevAPI DevDB DevTeam ATeam BTeam CTeam DService AService BService CService D

    Что это даёт

    Архитектура начинает поддерживать end‑to‑end доставку ценности без высокочастотных согласований между командами.

    Практики, поддерживающие поток

    • Loose coupling — минимальные зависимости между компонентами.
    • High cohesion — чёткие границы ответственности внутри компонентов.
    • Прозрачная совместимость версий и ожиданий между командами.
    • Кросс‑командное тестирование, чтобы не ломать интеграции.

    Практические правила коммуникаций

    • Интенсивное взаимодействие внутри команды.
    • Редкое и точечное взаимодействие между командами.
    • Средняя интенсивность между «сдвоенными» командами в рамках общих инициатив.

    Итог

    Закон Конвея — это инструмент диагностики: если архитектура «ломается», стоит начать с анализа коммуникаций и структуры команд, а не только с рефакторинга.

    Трекинг прохождения выключен. Включите его в настройках.

    Доказательство обучения

    Чтение — только начало. Перенесите идею в рабочий эксперимент и разберите результат.