Контекстная диаграмма C4 отвечает на простой вопрос: что представляет собой программная система, кто ею пользуется и с какими другими системами она связана? Она помогает понять границы системы до обсуждения её реализации.
При работе в общем пространстве для архитектурных диаграмм Boardmix сначала определите именно эти границы. В примере разберём платформу записи на услуги, которой пользуются клиенты и координаторы. Экраны, базы данных и инфраструктуру развёртывания оставим за пределами этой схемы.
Определите ответственность платформы записи
Рекомендации C4 по контекстным диаграммам предлагают сосредоточиться на одной программной системе, людях и внешних системах, которые непосредственно с ней взаимодействуют. Это обзорная схема: пользователи и ответственность здесь важнее протоколов и внутренних компонентов.
Представим платформу, в которой клиенты записываются на услуги, а координаторы управляют доступным временем. Платформа также обращается к внешнему платёжному сервису, передаёт запросы на отправку писем почтовому сервису и публикует изменения записей во внешней системе календаря.
В центральном блоке достаточно короткого описания: Платформа записи — управляет доступным временем, записями и их изменениями. Оно полезнее названия «Backend»: технический термин сам по себе не объясняет назначение системы.
Клиентское приложение и приложение координатора входят в одну платформу. Независимые сервисы оплаты, почты и календаря находятся вне её границ. Команда может отвечать за код интеграции, но не за сервис на другом конце соединения; на схеме эти зоны ответственности должны различаться.
Перечислите связи до расстановки блоков
Начните с короткого списка. Тогда аккуратная композиция не станет причиной пропуска важного участника или зависимости. Добавляйте элемент, только если можете объяснить его связь с рассматриваемой системой.
| Элемент | Роль в примере | Подпись связи |
|---|---|---|
| Клиент | Записывается на услугу и меняет запись | Создаёт и изменяет записи |
| Координатор услуг | Управляет расписанием оказания услуг | Управляет доступным временем и записями |
| Платёжный сервис | Внешняя система обработки платежей | Запрашивает обработку платежа |
| Почтовый сервис | Внешняя система доставки сообщений о записях | Запрашивает отправку сообщений о записи |
| Система календаря | Внешняя система, получающая изменения записей | Публикует изменения записей |
Первые две связи направлены от человека к платформе. Остальные три — от платформы к внешней системе. Подписи объясняют взаимодействие в этом направлении, а не изображают отдельно каждый запрос и ответ.
Например, связь «Запрашивает обработку платежа» показывает использование платёжного сервиса без отдельной обратной линии для каждого ответа. Если для обсуждения архитектуры важно асинхронное уведомление об оплате, добавьте и подпишите его как самостоятельную связь. Двусторонняя стрелка с подписью «данные» не заменяет объяснение взаимодействия.
Решите, какие детали здесь не нужны
Теперь рассмотрите элементы, которые команда может захотеть добавить. База данных важна для приложения, но не обязательно является отдельной внешней системой. В этом примере база записей входит в платформу, поэтому её место — на более подробной схеме.
| Предлагаемый элемент | Решение для контекстной диаграммы | Где показать подробности |
|---|---|---|
| База данных записей | Оставить внутри обобщённого блока платформы. | На диаграмме контейнеров с приложениями и хранилищами данных |
| Экран входа клиента | Не изображать экран как отдельную программную систему. | В пользовательском сценарии или макете экранов |
| Балансировщик нагрузки и реплики | Не добавлять топологию развёртывания. | На диаграмме развёртывания соответствующего окружения |
| Сотрудник поддержки | Добавить, только если он непосредственно работает с платформой в рамках рассматриваемого сценария. | На контекстной диаграмме, если прямая связь существует |
| Учётная система, в которую сотрудник вручную переносит отчёт | Не изображать несуществующую прямую интеграцию. | В отдельном описании передачи данных между сотрудниками, если это важно |
Последний пример важен: стрелка может создать впечатление, что соединение уже реализовано. Если координатор выгружает сведения и вручную вводит их в другую программу, это не то же самое, что передача из платформы. Покажите действующий порядок и отделите запланированные интеграции от существующих.
Можно нарисовать целевое состояние, но это должно быть понятно из заголовка. Не смешивайте действующую связь с платёжным сервисом и только предложенную связь с календарём без пояснения.
Подпишите схему так, чтобы она была понятна после встречи
Рекомендации C4 по обозначениям уделяют внимание понятным описаниям элементов, подписям связей и легенде. Стиль можно выбрать самостоятельно, но читатель не должен гадать, означает ли серый блок внешнюю систему, необязательную функцию или просто отсутствие выделения.
Дайте схеме конкретное название: «Платформа записи — контекст системы — предлагаемый пилот». В небольшой легенде разделите людей, рассматриваемую систему и внешние системы. Используйте те же названия, что и в документации проекта. Замена «координатора услуг» на «администратора» может незаметно изменить предполагаемые обязанности.
Пишите короткие описания, понятные без другого документа. «Почтовый сервис — доставляет подтверждения записи и сообщения об изменениях» информативнее одного логотипа поставщика. Логотип указывает на исполнителя, но не объясняет, зачем нужна зависимость.
Не считайте каждую линию шагом во времени. Контекстная диаграмма показывает отношения, а не точную последовательность оформления записи. Вопрос «оплата происходит до подтверждения?» требует схемы поведения, а не более длинной подписи на этой диаграмме.
Нарисуйте контекст платформы в Boardmix
Разместите платформу записи в центре доски Boardmix. Две пользовательские роли расположите с одной стороны, а три внешние системы — с другой, оставив место для подписей. Используйте простые фигуры и соединители: смысл задают названия, описания и границы, а не необычный значок сервера.
Добавляйте пять связей из списка по одной. Читайте каждую от источника к получателю: «Клиент создаёт и изменяет записи в платформе». Если фраза непонятна, уточните подпись прежде, чем добавлять следующую стрелку.
Рядом со схемой оставьте место для вопросов о границах. Например: «Координатор обновляет календарь напрямую или изменения публикует платформа?». Не подменяйте ответ двумя нарисованными маршрутами, будто оба уже подтверждены.
Откройте доску Boardmix, чтобы описать окружение своей системы. Пригласите тех, кто знает работу пользователей, и тех, кто разбирается в системных зависимостях: они часто замечают разные пропуски на одной схеме.
Добавляйте подробности, не меняя границ системы
После согласования контекста диаграмма контейнеров C4 может показать приложения и хранилища внутри платформы. «Контейнер» здесь — понятие модели C4, а не требование использовать Docker или другую среду выполнения контейнеров.
На следующем уровне один блок платформы может раскрываться в клиентское приложение, приложение координатора, прикладной сервис и хранилище записей. Сохраните названия внешних сервисов оплаты, почты и календаря. Вторая схема добавляет подробности к первой, а не вводит неожиданно другие границы продукта.
Если команда не согласна, входит ли календарь в платформу или находится снаружи, сначала разберите этот вопрос. Более подробный рисунок не устранит неопределённость ответственности. Уточните границы, затем выберите представление для следующего вопроса.
