Перейти к основному содержимому

Подходы к проектированию

ОБЯЗАТЕЛЬНОДЛЯ НОВИЧКОВ
Разработчику Архитектору Аналитику
Теория данных (раздел 3)

Модель и масштаб — Основы БД, опорные темы, проектирование БД, пакетная работа. Карта — о разделе.

Подходы к проектированию​

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

1. Code First​

Подход "Code First" предполагает, что отправной точкой является кодовая модель предметной области — классы, интерфейсы, методы. База данных рассматривается как вторичная структура, производная от кода. Её схема генерируется автоматически (например, через миграции), либо создаётся вручную по описанию, полученному из кода.

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

Преимущества:

  • Быстрый старт: разработчик сразу пишет код, минуя этап физического проектирования БД.
  • Естественное соответствие доменной модели: классы отражают сущности предметной области без искажений, навязанных структурой таблиц.
  • Легче обеспечить соответствие принципам SOLID и DDD: инкапсуляция поведения и данных происходит в классе, а не распыляется между кодом и триггерами.

Ограничения:

  • Риск некорректного физического представления данных. Например, ORM может сгенерировать таблицы без необходимых индексов или с неоптимальными типами.
  • Сложность интеграции с унаследованными системами, где схема БД фиксирована и не подлежит изменению.
  • Потенциальная потеря контроля над производительностью на уровне хранилища.

Примеры реализации — Entity Framework Core (.NET) и Django ORM (Python). В обоих случаях разработчик описывает классы, а ORM генерирует DDL-скрипты и управляет синхронизацией миграций.

2. Database First​

Подход "Database First" ставит во главу угла модель данных. Сначала проектируется логическая и физическая схема базы данных — таблицы, связи, ограничения целостности, индексы. Затем по этой схеме генерируется код: классы сущностей, методы доступа к данным.

Этот подход исторически был доминирующим в enterprise-разработке, особенно в 2000–2010-е годы, когда сложные хранимые процедуры, триггеры и представления являлись неотъемлемой частью бизнес-логики. Он остаётся актуальным в системах с высокими требованиями к целостности данных, в финансовых или медицинских приложениях, где данные первичны.

Преимущества:

  • Чёткий контроль над структурой данных. Требования нормализации, уникальности, ограничений проверяются на уровне СУБД.
  • Поддержка сложных аналитических запросов: оптимизация выполняется на уровне плана выполнения СУБД, а не ORM.
  • Простота совместной работы с DBA (администраторами баз данных), так как схема — основной артефакт.

Ограничения:

  • Сложность выражения поведения. Бизнес-логика, распределённая между кодом и хранимыми процедурами, становится трудноотлаживаемой и плохо тестируемой.
  • Проблемы с версионированием: изменения схемы требуют синхронизации между командами разработки и эксплуатации.
  • Угроза нарушения принципов инкапсуляции: таблица с десятком полей превращается в "божественный класс" с десятками методов.

Типичный стек — генерация классов через SQL Server Management Studio + Entity Framework (Database First mode) или Hibernate Tools для Java.

3. ETL и ELT​

Эти подходы применимы при проектировании систем интеграции и аналитики, где центральной задачей является перемещение, трансформация и агрегация данных между источниками и приёмниками. Хотя они возникли в контексте хранилищ данных (data warehousing), сегодня используются и в обработке потоков (streaming), и в микросервисных архитектурах.

ETL (Extract — Transform — Load)​

Последовательность операций чётко разделена во времени и в инфраструктуре:

  1. Extract — данные извлекаются из источников (реляционные БД, API, файлы, очереди).
  2. Transform — происходит обработка в промежуточной среде — очистка (удаление дубликатов, заполнение пропусков), нормализация (приведение к единому формату), агрегация (расчёт KPI, группировка), обогащение (добавление справочников).
  3. Load — результат загружается в целевую систему (хранилище, витрину данных, OLAP-куб).

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

Когда использовать ETL:

  • Когда требования к качеству данных строгие (например, регуляторная отчётность).
  • Когда целевая система ресурсоограничена (например, embedded-устройство или legacy-СУБД без поддержки сложных запросов).
  • Когда трансформация требует сложной логики, не реализуемой средствами СУБД (например, ML-модели, интеграция с внешними API).

Инструменты — Apache NiFi, Talend, SSIS, Informatica PowerCenter.

ELT (Extract — Load — Transform)​

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

  1. Extract — те же источники.
  2. Load — "сырые" данные (raw layer) помещаются в целевое хранилище без предварительной обработки. Часто сохраняются в формате, максимально близком к оригиналу (Parquet, Avro, JSON).
  3. Transform — трансформация выполняется внутри хранилища — SQL-скрипты, stored procedures, UDF, или облачные dataflow-движки (например, dbt — Данные build tool).

Когда использовать ELT:

  • Когда источник данных объёмный и изменяющийся (streaming-логи, IoT-устройства).
  • Когда аналитикам нужна гибкость: возможность перестроить витрину под новый запрос без перезапуска всего ETL-конвейера.
  • Когда целевая система — облачная аналитическая платформа, где вычислительные ресурсы масштабируемы и оплачиваются по использованию.

Ключевое отличие ETL и ELT — место и время ответственности за трансформацию. В ETL ответственность лежит на отдельном интеграционном слое; в ELT — на аналитической платформе и её пользователях. Это влияет на разделение ролей: в ETL доминирует инженер данных; в ELT — аналитик или Данные engineer с SQL-экспертизой.

Ограничение для ELT на локальной инфраструктуре

Переход от ETL к ELT стал массовым благодаря облачным MPP-СУБД (massively parallel processing), где вычисления и хранение масштабируются независимо. На классическом сервере без эластичных ресурсов ELT часто становится узким местом.

Как выбрать подход на практике​

Быстрый ориентир:

  • Code First подходит, когда продукт быстро эволюционирует, а команда управляет доменной моделью в коде.
  • Database First подходит, когда данные и их целостность критичны, а вокруг схемы уже построены процессы интеграции и отчётности.
  • ETL/ELT подходит, когда основная задача состоит в консолидации данных и аналитике, а не в транзакционной бизнес-логике.

Антипаттерны при выборе подхода​

  • Выбирать Code First в проекте, где DBA-команда и регуляторные требования требуют строгого контроля DDL.
  • Выбирать Database First, но переносить в SQL всю бизнес-логику приложения.
  • Смешивать ETL и ELT без границ ответственности, когда никто не понимает, где именно должна жить трансформация.
  • Делать "гибрид всего" без документирования архитектурных причин в ADR.

Короткий чек-лист перед стартом​

  1. Кто владелец изменений — разработка, DBA или data-команда?
  2. Где источник истины для бизнес-правил — код, SQL или контракты событий?
  3. Как будет происходить миграция схемы и откат?
  4. Какие метрики подтверждают, что подход подходит под нагрузку?

Если ответы размыты, лучше начать с Документации как инструмента проектирования и зафиксировать решения в ADR.

Смежные материалы​

Содержание