← назад к методологии · уровень 1 из 3

Что это

Классическая слоёная архитектура: Controller → Service → Repository. Без usecase-pattern, без явного разделения бизнес-операций, без доменного слоя. Сервис-классы держат логику, контроллеры её вызывают, репозитории ходят в БД. Это отправная точка — то, с чего начинают почти все.

Уровень 1 — не «недоделанный» уровень, а осознанный минимум: для части сервисов он остаётся достаточным навсегда.

Когда достаточно

  • Настоящий CRUD: справочник, админка, тонкая интеграция-прокси.
  • MVP или прототип со сроком жизни год-два, который потом перепишут или выключат.
  • Команда 1–3 человека, домен понятен за полчаса, инвариантов почти нет.
  • Бизнес-логика тонкая: проверки укладываются в несколько if.

Здесь полноценный Use Case Pattern, а тем более DDD, будут избыточны — заплатите за структуру, которая не окупится.

Что должно быть

Тонкие контроллеры. Контроллер парсит запрос, зовёт сервис, заворачивает ответ — и ничего больше.

Сервисы по предметным областям. OrderService, CustomerService — логика и обращения к репозиториям внутри.

Транзакция на уровне сервисного метода. Один @Transactional на операцию — всё или ничего.

Persistence — jOOQ или JPA, одна модель данных: то, что приходит из API, и то, что лежит в БД, связано простым маппингом. Никаких отдельных доменных моделей и Value Object — они появятся выше.

Где это ломается

Слоёный подход живёт ровно до момента, когда бизнес-операции перестают быть явными:

  • OrderService обрастает 20–30 методами, и непонятно, какие из них — реальные бизнес-операции, а какие — служебные.
  • Одну операцию вызывают из трёх мест с чуть разными проверками — расходятся, появляется баг.
  • Нет единой точки, где видно «что вообще умеет сервис»: список операций приходится собирать глазами по сигнатурам.
  • Метрики и аудит на операцию приходится прикручивать руками в каждом методе.

Это не «плохой код» — это предел слоёной модели. Дисциплины «каждая операция явно выделена» в ней просто нет.

Что фиксируется в спеке

На этом уровне Use Case спецификация минимальна: глоссарий, роли, ER-схема и список операций. Агрегатов и доменных событий нет — они помечаются «не применимо на Уровне 1». Домен-юнит (центральная сущность) всё равно выносится в отдельный файл — формат раскладки един для всех уровней.

Признаки, что пора на уровень 2

  • Сервис-классы разрослись, и операции в них не различить.
  • Хочется на каждую операцию автоматические метрики, аудит, единый способ обработки ошибок.
  • Появляется потребность тестировать бизнес-операцию изолированно, без поднятия web-слоя.

Тогда — Уровень 2: Use Case Pattern: каждая бизнес-операция выделяется в отдельный UseCase + Handler.

Что почитать рядом