Архитектура веб-приложения в модели C4

Зачем

Команда подготавливает два согласованных представления архитектуры своего проекта по модели C4:

1. System Context diagram: разрабатываемая система, её пользователи и внешние программные системы.
2. Container diagram: основные приложения и хранилища данных внутри разрабатываемой системы.

Используйте уже подготовленное описание проекта и существующую архитектурную схему, если она есть. Повторно описывать идею продукта и пользовательские сценарии не требуется.

Стартовый набор

Работа командная, над собственным проектом. Нужны материалы проекта с прошлых занятий и защиты «Представление», а также архитектурная схема, если она уже есть.

Что нужно сделать

System Context diagram

Диаграмма должна показывать:

• одну программную систему, которую разрабатывает команда;
• основные роли людей, непосредственно взаимодействующих с системой;
• внешние программные системы, непосредственно взаимодействующие с ней;
• направленные и подписанные связи между элементами.

Для каждого элемента укажите имя, тип (Person или Software System) и краткое назначение или ответственность.

На System Context diagram не показывайте frontend, backend, базу данных, отдельные сервисы и технологии реализации.

Container diagram

Диаграмма должна раскрывать внутреннее устройство программной системы, показанной на System Context diagram. Покажите:

• границу разрабатываемой системы;
• основные приложения и хранилища данных внутри неё;
• людей и внешние системы, которые непосредственно взаимодействуют с контейнерами;
• взаимодействия между контейнерами.

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

В C4 контейнером считается отдельно запускаемое приложение или хранилище данных. Это не обязательно Docker-контейнер.

На Container diagram не показывайте классы, функции, контроллеры, страницы интерфейса, таблицы базы данных и другие детали кода.

Правила нотации

Для обеих диаграмм:

1. У диаграммы есть название, содержащее её тип и название системы.
2. У каждого элемента указаны имя, тип и краткое описание.
3. Каждая связь направлена и подписана.
4. Подпись связи соответствует направлению стрелки и описывает конкретное действие, а не абстрактное «использует».
5. Для контейнеров указаны технологии либо явно отмечено, что технология ещё не выбрана.
6. Цвета, формы и типы линий используются последовательно.
7. На диаграмме есть легенда, объясняющая используемые обозначения.
8. Одинаковые люди и внешние системы одинаково названы на обеих диаграммах.
9. На одной диаграмме не смешиваются элементы разных уровней C4.
10. Диаграмму можно понять без дополнительного устного объяснения.

Ход работы

1. Определите границу системы

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

2. Определите окружение системы

   Составьте список ролей людей, непосредственно работающих с системой, и внешних программных систем, с которыми происходит прямой обмен данными.

   Не используйте общее слово «пользователь», если разные роли выполняют разные действия. Не добавляйте внешнюю систему, если разрабатываемое приложение не взаимодействует с ней напрямую.

3. Постройте System Context diagram

   Расположите разрабатываемую систему в центре и добавьте её пользователей и внешние программные системы. Подпишите все элементы и связи. Проверьте, что на диаграмме нет внутренних деталей реализации.

4. Определите контейнеры

   Составьте список основных приложений и хранилищ данных внутри системы. Для каждого предполагаемого контейнера проверьте:

   • является ли он отдельно запускаемым приложением или хранилищем данных;
   • выполняет ли он отдельную ответственность;
   • известна ли его основная технология;
   • с какими элементами он взаимодействует.

   Не разделяйте приложение на дополнительные сервисы только ради усложнения схемы. Если проект предполагает единый серверный монолит, покажите его одним контейнером.

5. Постройте Container diagram

   Покажите границу разрабатываемой системы и разместите внутри неё контейнеры. Добавьте людей и внешние программные системы, непосредственно взаимодействующие с контейнерами. Подпишите направления, назначение и технологии взаимодействий.

6. Проверьте согласованность диаграмм

   Убедитесь, что:

   • обе диаграммы описывают одну и ту же программную систему;
   • названия системы, людей и внешних систем совпадают;
   • Container diagram раскрывает систему, показанную на System Context diagram;
   • внешние системы не превратились во внутренние контейнеры;
   • на System Context diagram нет контейнеров;
   • на Container diagram нет компонентов и деталей кода;
   • все элементы и связи соответствуют правилам нотации.

7. Зафиксируйте открытые вопросы

   Если архитектурное решение ещё не принято, не подменяйте его случайным выбором. Отдельно перечислите оставшиеся вопросы, например: не выбран тип базы данных, не определён способ авторизации, не решено, нужна ли отдельная фоновая обработка, требуется уточнить способ интеграции с внешней системой.

Чек-лист перед сдачей

System Context diagram

• Показана одна разрабатываемая программная система.
• Показаны основные роли людей.
• Показаны непосредственно связанные внешние системы.
• У каждого элемента есть имя, тип и описание.
• Все связи направлены и подписаны.
• Нет внутренних частей приложения и технологий реализации.

Container diagram

• Видна граница разрабатываемой системы.
• Внутри находятся только приложения и хранилища данных.
• Для каждого контейнера указаны ответственность и технология.
• Все связи направлены и подписаны.
• Для взаимодействий между контейнерами указаны технологии или протоколы, если они выбраны.
• Нет классов, контроллеров, таблиц базы данных и других деталей кода.

Согласованность

• Названия элементов совпадают на обеих диаграммах.
• Используемые цвета, формы и линии объяснены в легенде.
• Уровни C4 не смешиваются.
• Обе диаграммы можно понять без устного объяснения.

Что сдаём

Один файл или одну страницу в репозитории проекта, содержащую:

1. название и краткое назначение системы;
2. System Context diagram;
3. Container diagram;
4. список открытых архитектурных вопросов, если они остались.

Ссылку на файл — в топик «Практики», одно сообщение от команды.

Зачтено, если

Оценка выставляется за общий результат команды.

Балл	Когда ставится
1	Подготовлены обе диаграммы; правильно разделены уровни System Context и Container; элементы имеют имена, типы и понятные описания; связи направлены и содержательно подписаны; у контейнеров указаны ответственности и технологии; диаграммы согласованы между собой; соблюдены основные правила нотации.
0.5	Подготовлены обе диаграммы и общая архитектура проекта понятна, но результат требует существенной доработки. Например: частично смешаны уровни абстракции; отсутствуют описания некоторых элементов; часть связей не подписана или имеет непонятное направление; не везде указаны технологии контейнеров; есть расхождения между двумя диаграммами; отсутствует или неполна легенда.
0	Отсутствует одна из двух обязательных диаграмм; или диаграммы не описывают представленный командой проект; или уровни абстракции смешаны настолько, что структуру системы невозможно понять; или работа в целом не достигает требований на 0.5 балла.

Типовые грабли

• На System Context diagram нарисованы frontend, backend и база данных.
• Внешняя система, с которой приложение не обменивается данными напрямую, попала на схему «для полноты».
• Один «Пользователь» вместо разных ролей, которые делают разные вещи.
• Связи подписаны словом «использует».
• Монолит разрезан на сервисы только ради сложной схемы.
• Технология выбрана наугад, чтобы не оставлять пустое поле, вместо открытого вопроса.