Проектирование предметной области - практика

Добро пожаловать к третьему упражнению курса!
На этом этапе мы уже научились выявлять ключевые сущности FoodFleet и их базовые атрибуты.
Теперь пришло время расширить доменную модель, используя детали из функциональных требований и UI-спецификаций.

Это упражнение помогает глубже понять предметную область и подготовить основу для последующего проектирования модулей и архитектуры UI.

Цель упражнения

Твоя задача — завершить первичное проектирование предметной области FoodFleet, добавив:

• недостающие сущности,
• ключевые атрибуты,
• связи между сущностями.

В качестве отправной точки можно использовать стартовую модель из предыдущего урока (список сущностей + атрибуты).

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

1. Пройтись по функциональным требованиям FoodFleet

В спецификации есть множество повторяющихся сущностей и действий:

• заказ,
• ресторан,
• категория меню,
• блюдо,
• пользователь,
• корзина,
• водитель,
• доставка и т.д.

Любое существительное, за которым следует действие, — кандидат на сущность или атрибут.

2. Пройтись по UI-спекам

Открой Figma и внимательно осмотри страницы:

• главная,
• карточка ресторана,
• меню,
• экран корзины,
• экран оформления заказа.

UI часто раскрывает:

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

3. Добавить недостающие сущности и атрибуты

На данном этапе не нужно создавать идеальную модель, она будет уточняться позже.
Фокус должен быть на:

• основных данных,
• характеристиках, которые влияют на интерфейс,
• отношениях между сущностями.

Например:

**Restaurant**
- id
- name
- heroImage
- deliveryFee
- deliveryTime
- categories[] → RestaurantCategory
- items[] → FoodItem

4. Отдельно отметить связи между сущностями

В доменной модели любого приложения связи — ключевой момент.
Примеры связей, которые обязательно должны быть отражены:

• Restaurant → FoodItem
• Restaurant → Category
• Customer → Cart
• Order → Customer
• Order → Restaurant
• Order → Driver
• Cart → FoodItem

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

Бонус: визуальная диаграмма Mermaid

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

Просто возьмите получившийся у вас список сущностей со свойствами и связями, скормите его любой ЛЛМ типа Алисы, ЧатГПТ и т.д. и попросите ее преобразовать ее в диаграмму классов Mermaid. Например вот таким запросом

Restaurant: id, name, deliveryTime, items[]
FoodItem: id, title, price

преобразуй в диаграмму классов Mermaid

В результате вам вернется кусок кода, который можно вставить например на сайте Mermaid И вы получите диаграмму как на рисунке ниже:

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

Что важно помнить

• Точность не требуется — это черновой этап.
• Операции можно пропустить — они важны позже.
• Главный фокус — сущности и связи между ними.
• Это упражнение готовит фундамент для архитектуры модулей, которую мы будем строить дальше.

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