Закон Конвея
«Организации проектируют системы, структура которых копирует структуру коммуникаций внутри организации». Это наблюдение, не закон природы.
Что это / Зачем
- Архитектура кода неминуемо отражает структуру команды и каналы общения.
- Маленькая команда → монолит (все лезут в общий код, патчат на лету).
- Большая распределённая команда → микросервисы / модульная архитектура (модули — границы команд).
- В open source это особенно видно: репозиторий = граница владельцев.
Связь с SRP
- SRP — это первое следствие закона Конвея, применённое к коду.
- «Класс должен иметь одну причину для изменения» = одну команду стейкхолдеров, которая запрашивает изменения.
- Если за один класс отвечают разные команды → конфликты при изменениях → нарушение SRP.
Применение в обратную сторону
«Inverse Conway Maneuver»: чтобы получить желаемую архитектуру, сначала формируй команду под неё. Хочешь микросервисы — сделай команды по доменам.
Признаки
- Один модуль ломается = ломается работа нескольких команд → плохая граница.
- Изменение в маленькой фиче требует согласований 5 команд → плохо проведена граница владения.
- Frontend-команда не может выпустить релиз без backend-команды → артефакт Conway.
Антипаттерн
Команда A пишет домен.
Команда B пишет инфраструктуру.
Но оба пишут в один модуль User.js.
→ Постоянные merge conflicts, обвинения, размытая ответственность.
→ Нужно либо разделить модуль, либо объединить команды.
🎓 Источники
- 🎓 [Single Responsibility Principle and Conway's Law] · 2019-10-17 · YouTube
- «Это наблюдение, не закон природы».
- «В небольших командах часто получается монолитный кусок кода. Все полезли, открыли чужой код, на лету пропачили».
- Связь Conway ↔ SRP: разделение ответственности отражает разделение команд.