Software Architect · Модуль 04
Даже сильная команда проигрывает системе, которую невозможно удержать в голове.
Cognitive load · bounded context · Conway's Law
Архитектура должна снижать лишнюю сложность, а не демонстрировать интеллектуальную мощь автора.
Не вся сложность одинаковая
Пилоту нужно знать аэродинамику самолёта, но не нужно помнить серийный номер каждого болта в кресле пассажира.
Intrinsic cognitive load — сложность самой предметной области. В финансовой системе есть деньги, проводки, лимиты, регуляторика. Это нельзя просто убрать. Extraneous cognitive load — лишняя сложность, созданная архитектурой: случайные зависимости, магия, неочевидные side effects, пять способов сделать одно и то же.
Задача архитектора — защищать команду от extraneous load. Хорошая архитектура не делает домен простым, но делает его понятным.
Bounded context снижает шум
В аэропорту слово «gate» значит выход на посадку. В логистике gate может значить ворота склада. Одно слово, разные миры.
Bounded context — граница, внутри которой модель и язык согласованы. Customer в billing и customer в support часто не один и тот же объект. Попытка сделать универсальную модель «клиента» может увеличить cognitive load: каждый разработчик должен помнить все исключения всех доменов.
Хороший bounded context позволяет инженеру работать локально: понять язык, инварианты и зависимости именно этой области.
Если изменение требует держать в голове всю систему, границы проведены плохо.
Пример: команда владеет checkout
Ресторанная смена отвечает за кухню целиком: ингредиенты, процесс, выдачу, качество. Ей не нужно спрашивать офис при каждом заказе.
Checkout-команда владеет cart, pricing snapshot, payment intent, order creation и failure handling. У неё есть понятные API к catalog и identity. Она не лезет в warehouse напрямую, а публикует событие OrderPlaced.
Такой разрез снижает cognitive load: команда понимает свой поток end-to-end и не держит всю компанию в голове.
Антипример: слой shared everything
Общая кладовка удобна, пока каждый не начинает складывать туда свои инструменты без подписей.
Папка shared часто превращается в мусорный контейнер: validators, formatters, domain models, API clients, permissions, constants. Любое изменение становится опасным, потому что никто не знает, кто ещё использует этот код.
Shared код должен быть либо очень стабильным, либо очень маленьким. Иначе он увеличивает coupling и cognitive load.
- Можно ли объяснить модуль без соседних модулей? - Где в системе слишком много implicit knowledge? - Какие shared части меняются слишком часто? - Совпадают ли team boundaries и architecture boundaries?