Часто задаваемые вопросы

Должны ли строки представлять зависимости или поток данных?

Это ваш выбор. Иногда лучше работают диаграммы, показывающие взаимосвязи зависимостей (например, использование, чтение из и т.д.), а иногда лучше работает поток данных (например, события обновления клиента). Что бы вы ни выбрали, убедитесь, что описание линии совпадает с направлением стрелки.

Также стоит помнить, что большинство взаимосвязей могут быть выражены любым способом, и чем более четко вы их сформулируете, тем лучше. Например, описание взаимосвязи как “отправляет события обновления клиентов в” может быть более наглядным, чем просто “события обновления клиентов”.

Будут ли диаграммы быстро устаревать?

Из-за иерархической природы модели C4 каждая диаграмма будет меняться с разной скоростью.

• Диаграмма системного контекста: В большинстве случаев диаграмма системного контекста меняется очень медленно, поскольку она описывает ландшафт, в котором работает программная система.
• Диаграмма контейнера: Если вы не создаете программную систему, в которой широко используются микросервисы или бессерверные лямбда-выражения/функции и т.д., диаграмма контейнера также будет меняться относительно медленно.
• Диаграмма компонентов: Для любой программной системы, находящейся в стадии активной разработки, диаграммы компонентов могут часто меняться по мере того, как команда добавляет, удаляет или перестраивает код в связные компоненты.
• Диаграмма кода: Диаграммы кода уровня 4 (например, класса) потенциально могут очень быстро устареть, если кодовая база находится в стадии активной разработки. По этой причине рекомендуется (1) не создавать их вообще или (2) генерировать их на лету используя инструменты такие как IDE.

Разумеется, вышесказанное применимо только в том случае, если вы создаете свои диаграммы C4 вручную. Автоматическое создание ваших диаграмм гарантирует, что они всегда будут актуальными и будут отражать реальность. Возможные подходы к этому включают:

• Системный ландшафт/контекстные диаграммы: Использование существующих каталогов систем/сервисов (например, Backstage, ServiceNow и т.д.) в качестве источника данных для идентификации программных систем и взаимосвязей.
• Диаграммы контейнеров: Анализ файлов журналов или использование данных OpenTelemetry в качестве источника данных для идентификации микросервисов и взаимосвязей.
• Диаграммы компонентов: Статический анализ/реверс-инжиниринг кода как источника данных для идентификации компонентов и их взаимосвязей.
• Диаграммы развертывания: Анализ определений “инфраструктура как код” (например, Terraform, CloudFormation и т.д.) или обратное проектирование конфигурации облачной среды в качестве источника данных для идентификации элементов развертывания.

Модель C4 против UML, ArchiMate и SysML?

Хотя существующие нотации, такие как UML, ArchiMate и SysML, уже существуют, многие команды разработчиков программного обеспечения, похоже, их не используют. Часто это происходит из-за того, что команды недостаточно хорошо знают эти обозначения, считают их слишком сложными, считают, что они несовместимы с гибкими подходами или не имеют необходимого инструментария.

Если вы уже успешно используете одну из этих нотаций для описания архитектуры программного обеспечения и оно работает, придерживайтесь его. Если нет, попробуйте модель C4. И не бойтесь дополнять диаграммы C4 диаграммами состояний UML, временными диаграммами и т.д., если это необходимо.

Можем ли мы объединить C4 и arc42?

Да, многие команды делают это, и модель C4 совместима с шаблоном документации arc 42 следующим образом.

• Контекст и область применения => Диаграмма системного контекста
• Просмотр строительных блоков (уровень 1) => Схема контейнера
• Просмотр строительных блоков (уровень 2) => Схема компонентов
• Представление структурного блока (уровень 3) => Схема кода (например, класса)