Моделирование предметной области (Domain Modeling)

В этом уроке мы разберём один из самых мощных инструментов архитектора — Domain Modeling или на русском Проектирование предметной области, еще иногда используется дословный перевод - моделирование домена.
Это метод, который помогает понять устройство предметной области FoodFleet, определить ключевые сущности, их атрибуты, операции и взаимосвязи.
Моделирование домена станет фундаментом для проектирования модулей, структуры данных и UI-архитектуры нашего приложения.

Что такое Domain Modeling

Domain Modeling — это процесс выявления основных сущностей системы и описания того, какими данными и поведением они обладают. В контексте любого приложения это помогает ответить на вопросы:

• Какие сущности формируют наш продукт?
• Какие у них свойства?
• Какие действия они выполняют?
• Как они взаимодействуют между собой?
• Какие данные нужны для построения интерфейса?

Этот инструмент помогает решить огромный спектр архитектурных задач и одинаково полезен для:

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

Где искать сущности FoodFleet

1. Функциональные требования

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

Например, в требованиях FoodFleet много действий, связанных с понятиями "Пользователь", "Ресторан", "Блюдо" — значит, это вероятные ключевые сущности системы. Мы читаем описание, отмечаем повторяющиеся понятия и собираем их в список.

Если требование говорит:

«Пользователь добавляет блюда в корзину»
мы получаем минимум 3 сущности: Customer, FoodItem, Cart и одну операцию: addToCart().

В результате работы со спецификацией у нас может появиться примерно такой список:

• Customer (для сущности пользователя)
• Restaurant (для сущности ресторана)
• Food Item (для сущности блюда)
• Cart (для сущности корзины)
• Order (для сущности заказа)

2. UI-макеты (Figma)

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

Например на странице ресторана можно обнаружить атрибуты:

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

Каждый из этих элементов — потенциальный атрибут или связь сущности Restaurant.

Пример списка сущностей FoodFleet

Один из удобных способов фиксировать доменные сущности — в виде простых списков. Вы просто выписываете имена сущностей и каждому из них добавляете список атрибутов. Например:

`Customer`
- id
- name
- email
- favorites[]
- addToFavorites()

`Restaurant`
- id
- name
- logo
- heroImage
- deliveryTime
- deliveryFee
- categories[]
- items[]

`Cart`
- id
- items[]
- totalPrice
- addItem()
- removeItem()

Этот список постепенно уточняется, превращаясь затем в ER-диаграмму или диаграмму классов.

Зачем нужно моделирование домена

Давайте еще раз повторим зачем нам нужно вжумчиво заниматься моделированием предметной области.

1.Правильное именование

Во-первых, хорошая проработка сущностей дает нам единую систему именования для всего проекта. Если мы заранее договорились, что сущность называется Restaurant, то и весь код будет единообразным, мы будем использовать имена компонентов и переменных типа:

• RestaurantCard
• RestaurantPage
• getRestaurantInfo()
• restaurant.items

Без модели у разработчиков появляются "store", "vendor", "shop", "place" — хаос.

2.Нормализация данных и выравнивание под UI

Часто бывает так, что структура ответов сервера не подходит для использования в интерфейсе. Прежде чем работать с данными нам нужно их преобразовать в удобный для нас вид, чтобы избежать сильной вложенности или необходимости поиска в больших массивах данных. Например сервер отвечает нам в таком виде:

{
  "vendor": {
    "details": {
      "meta": {
        "name": "Sushi Story"
      }
    }
  }
}
json

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

3.Разделение ответственности

Обсуждение операций на уровне домена позволяет заранее определить, кто именно отвечает за действие.

Например операция addToCart задействует несколько сущностей Customer, FoodItem и Cart. А в итоге кому будет принадлежать логика? Будет ли этот метод методом объекта Customer или Cart? Эти решения проще принять на ранней стадии, чем когда уже создан десяток компонентов и API-эндпоинтов.

Что будет дальше?

После моделирования предметной области мы сможем:

• выстроить структуру модулей FoodFleet,
• определить слой данных,
• продумать архитектуру клиентского приложения,
• визуализировать модель в виде диаграммы (классы, ER-диаграммы),
• перейти к проектированию модулей и компонентов.

Domain Modeling — первый кирпич в архитектуре, на котором будет держаться весь фронтенд FoodFleet.