Упражнение 1: Разбор решения

Надеюсь, ты попробовал(а) построить свою диаграмму контейнеров — это одно из самых полезных упражнений для любого архитектора.

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

Мой вариант диаграммы FoodFleet

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

Еще мне нравится результат который дает Structurizr. Ты можешь попробовать результат здесь. Используй следующий код как основу:

workspace "FoodFleet - Container Diagram" {

    model {
        user = person "Пользователь" "Делает заказ, используя клиентское приложение."
        restaurant = person "Ресторан" "Получает и обрабатывает заказы через приложение для вендоров."
        driver = person "Водитель" "Собирает и доставляет заказы, используя мобильное приложение."

        paymentSystem = softwareSystem "Внешняя платёжная система" "Обрабатывает платежи и возвраты."
        adminSystem = softwareSystem "Админка" "Используется сотрудниками FoodFleet для модерации и поддержки."

        foodFleet = softwareSystem "Сервис FoodFleet" "Платформа для доставки еды, объединяющая клиентов, рестораны и курьеров." {
            
            webApp = container "Клиентское приложение" "Веб-приложение для клиентов, позволяющее искать рестораны и оформлять заказы." "Next.js"
            restaurantApp = container "Ресторанное приложение" "Приложение для ресторанов, позволяющее получать заказы и управлять меню." "React SPA"
            driverApp = container "Водительское приложение" "Мобильное приложение для курьеров, предназначенное для обработки доставок." "Native"
            websocketServer = container "Веб-сокет сервер" "Передаёт события в реальном времени пользователям." "Node.js"
            coreApi = container "Core API" "REST API, объединяющий все приложения и взаимодействующий с БД." "Java / .NET"
            database = container "База данных" "Основное хранилище данных заказов, пользователей и ресторанов." "PostgreSQL"
        }

        user -> webApp "Делает заказы через"
        restaurant -> restaurantApp "Получает заказы через"
        driver -> driverApp "Доставляет заказы через"

        webApp -> coreApi "Работает с заказами через REST API"
        restaurantApp -> coreApi "Работает с заказами через REST API"
        driverApp -> coreApi "Работает с заказами через REST API"

        coreApi -> database "Чтение/запись данных"
        coreApi -> websocketServer "Создаёт события для отправки пользователям"
        websocketServer -> webApp "Отправляет события в реальном времени"

        coreApi -> paymentSystem "Процессит оплаты"
        coreApi -> adminSystem "Передаёт данные для модерации и аналитики"
    }

    views {
        container foodFleet Container Diagram {
            include *
            autolayout lr
            title "Диаграмма контейнеров системы FoodFleet"
        }

        theme default
    }
}

Примерно так получится в итоге:

---

Как построена диаграмма

1. Система как рамка
   В центре изображён наш сервис FoodFleet — это «коробка», внутри которой размещены все контейнеры системы.
   Вверху — пользователи (Клиент, Ресторан, Водитель),
   внизу — внешние системы (Платёжная система и Админка).

2. Контейнеры внутри системы
   Каждый контейнер обозначен отдельным блоком:

   • Клиентское приложение (Next.js)
   • Ресторанное приложение (React SPA)
   • Водительское приложение (Native)
   • Core API (Java / .NET)
   • WebSocket-сервер (Node.js)
   • База данных (PostgreSQL)

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

3. Связи и стрелки
   Все элементы соединены подписанными стрелками:

   • Пользователи взаимодействуют со своими приложениями.
   • Все приложения используют Core API для работы с заказами.
   • WebSocket-сервер отправляет события в реальном времени клиентам.
   • API взаимодействует с базой данных и внешними сервисами.

4. Группировка клиентов
   Чтобы не перегружать диаграмму множеством стрелок, я обозначил все клиентские приложения (Web, Restaurant, Driver) общей пунктирной линией. Это не часть официальной нотации C4, но помогает визуально упростить схему и сделать связи более читаемыми.

Нестандартные элементы (и почему они допустимы)

C4-модель задаёт базовые правила, но главная цель архитектурной диаграммы — понятность, а не следование догмам.

Можно добавлять:

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

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

Зачем всё это

Давайте еще раз проговорим зачем нам контейнерная диаграмма:

• Помогает увидеть архитектуру целиком.
• Делает систему понятной для новых участников.
• Формирует единый словарь для команды (все говорят о компонентах одинаковыми терминами).
• Легко обновляется при изменениях и может использоваться в документации.

Итого

• Мы построили диаграмму контейнеров (или контейнерную диаграмму, как вым удобнее) FoodFleet (уровень 2 модели C4).
• Разобрали, какие элементы в неё входят и как их соединять.
• Поняли, что главное - ясность, а не строгое следование нотации.
• Определили контейнер, с которым будем работать дальше - Клиентское приложение (Next.js).

На схеме ты можешь увидеть Клиентское приложение (Next.js) -
это тот контейнер, архитектуру которого мы будем проектировать дальше и с ним мы будем работать на протяжении следующих модулей.