Переход от контейнеров к модулям (C4 Level 3)

В предыдущих уроках мы познакомились с моделью C4 и рассмотрели два её уровня:
System Context Diagram и Container Diagram (Контекстная диаграмма и диаграмма контейнеров).
Эти уровни помогли нам понять, что представляет собой FoodFleet и из каких крупных частей состоит система.

Теперь пришло время приблизиться ещё ближе — к третьему уровню модели C4, где мы разбираем внутреннее устройство контейнера, то есть Фронтенд-приложения FoodFleet.
На этом уровне мы выявляем ключевые строительные блоки приложения, которые C4 называет components. Однако во фронтенд-разработке слово «компонент» обычно ассоциируется с UI-компонентами, поэтому для архитектуры мы будем использовать термин модули.

Что такое модули?

Модули — это верхнеуровневые части приложения, каждая из которых отвечает за отдельную функциональную область.
Если представить FoodFleet как набор мини-приложений внутри одного, то именно модули и являются этими мини-приложениями.

Разбивка на модули — это первый шаг архитектурной декомпозиции.
Она помогает:

• организовать структуру кода;
• распределить ответственность между частями приложения;
• упростить понимание и поддержку проекта;
• разделить работу между членами команды.

Как определить модули?

Самый простой и практичный способ — посмотреть на маршруты приложения (routes).
Их ещё нет в коде, но мы можем предсказать их структуру, опираясь на UI-спецификацию и требования проекта.

Так мы формируем первый черновой список модулей.
Например, для FoodFleet можно выделить:

• Home
• Login
• Delivery / Pickup
• Restaurant Profile
• Menu Item
• Search
• Cart

Это не финальный список — названия и структура могут измениться — но он создаёт основу для будущей архитектуры.

Модули не всегда совпадают с сущностями

Иногда модуль и сущность домена совпадают: например, Restaurant может быть и сущностью, и модулем. Но это не правило. Некоторые сущности не становятся модулями, а некоторые модули вообще не являются сущностями.

С другой стороны: Search — важная часть приложения, со своими состояниями, логикой, компонентами. Но «поиск» — это не сущность домена. Это действие. Тем не менее Search — это полноценный модуль.

Модули не обязаны соответствовать маршрутам

Иногда маршрут вложен в другой, но модуль всё равно должен быть отдельным. Например, Menu Item — вложенный маршрут внутри Restaurant. Но объект меню достаточно сложный (у него могут быть опции, модификаторы, категории), чтобы быть самостоятельным модулем. Есть и обратная ситуация: модуль может существовать вне маршрутов. Например, Корзина (Cart) отображается на всех страницах и не имеет своего route, но это один из самых важных модулей приложения.

Как модули взаимодействуют между собой

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

Например:

• Модуль Menu Items напрямую связан с Restaurant — без ресторана меню не существует.
• Модуль Cart зависит от данных ресторанов и блюд.
• Модуль Search использует сущности из разных других модулей.

Поэтому важно понимать модули не как независимые системы, а как сотрудничающие части одного приложения.