С чего начинать проектирование

Есть несколько подходов: начать с БД, с классов, с API, с UI. Все имеют ограничения. Согласно автору, для серьёзных систем — сначала информационная модель, из неё выводится всё остальное.

Возможные точки входа

Подход Когда применим Минус
БД-first (SQL-структура) Серьёзные информационные системы Игнорирует UX, API ужимаются под таблицы
Классы-first (ООП-модель) Маленькие проекты Не учитывает реляционность, проекции
API-first Несколько клиентов одного бэкенда Структуры БД пляшут под API
UI-first Заказчик мыслит экранами Структуры данных подгоняют под формы

Информационная модель — корень всего

  • Сначала рисуется информационная модель (UML, IDEF1X).
  • Из неё выводится: структура БД, классы, API, UI, программные модули.
  • Одна блок-схема → все артефакты согласованы.

Когда модель в голове не помещается

  • 850+ таблиц в медицинской/госсистеме — на одном листочке не нарисуешь.
  • Нужны срезы (view): отдельная схема для модуля «Кадры», отдельная для «Финансов».
  • Каждый bounded context (из DDD) имеет свою подсхему.

Признаки правильного входа

  • Можно дать модель новому разработчику и он поймёт систему за день.
  • Изменение требования → понятно, какую часть модели править → всё остальное следует.
  • Можно сгенерировать стартовый код (миграции, DTO, сервисы) из модели.

Антипаттерн: путаница БД и UI

Заказчик: «Сделайте таблицу клиентов как в Excel — там колонки A, B, C…»
Разработчик: «Хорошо», лепит таблицу БД с колонками A, B, C
→ через год выясняется, что C — это вычисляемое поле от B
→ через два года — что B нужно нормализовать на 5 сущностей

🎓 Источники

  • 🎓 [С чего начинать проектирование] · 2025-02-10 · YouTube
    • «Сначала информационная модель, рисуем в UML или IDEF1X».
    • «Из одной блок-схемы появляется структура данных, API, UI, классы».
    • В системах на 850 таблиц — нужны срезы модели.
    • Альтернативная позиция: SQL-first — sophisticated подход для серьёзных систем. UI-first — частая ошибка.

См. также