Большинство команд используют C4 как способ «нарисовать архитектуру». Это ошибка.

Большинство команд используют C4 как способ «нарисовать архитектуру». Это ошибка.

Если у вас десяток микросервисов, устаревшая документация и два дня на решение, красивые схемы не спасают. Спасает другой порядок мышления: сначала границы системы, потом ответственность сервисов, и только затем детали реализации.

C4 полезен не потому, что он визуальный, а потому что он дисциплинирует вопросы:
— кто владеет сценарием;
— где проходит граница принятия решения;
— что сломается, если добавить кэш в API‑шлюз;
— как изменится поведение при таймауте, просадке БД или частичном отказе.

Вместо «давайте обсудим архитектуру» команда получает проверяемую модель. Это уже не презентация, а рабочий артефакт: его можно версионировать, обновлять и использовать как код 📌

Для системного аналитика это важнее, чем очередной UML ради UML. Схема должна не впечатлять, а снижать риск неверного решения.