Use Case Pattern: пошаговый гид по применению

Практический гид: что и в каком порядке делать, чтобы получить результат. Два сценария — один UseCase за 3 минуты и целый сервис от спеки до прода за день-два. Команды, ожидаемый результат, чек-листы и антипаттерны.

Практический гид: что и в каком порядке делать, если хочется получить результат. Два сценария — маленькая задача (один UseCase за 3 минуты) и целый сервис от спеки до прода (день-два). Решение какой выбрать — в блоке ниже.

Перед началом убедитесь, что инструменты установлены: Скиллы UCP — каталог и установка. Дальше — конкретные команды, чего ждать, как читать результат.

Сценарий 1: один UseCase за 3 минуты

Самый частый кейс: «надо добавить новую операцию в существующий сервис». Проверка статуса заказа, отмена платежа, выдача отчёта — одна бизнес-операция, одна команда.

Здесь нужен только usecase-pattern-skills. superpowers и context7 не нужны, оверкилл.

Что делаете

Открываете Claude Code в проекте и вызываете один скилл:

/ucp-pattern-design Команда «отменить заказ» с проверкой статуса DRAFT|PAID и ABAC по customerId

Что получаете

Скилл за 30 секунд возвращает:

CancelOrderUseCase — record, реализующий UseCaseCommand<Void> или UseCaseCommand<Order>
CancelOrderHandler — @Component с @Transactional, бизнес-логика проверки статуса и ABAC внутри
Контроллер с @PreAuthorize("hasRole('customer')"), реализующий OpenAPI-генерируемый интерфейс
Юнит-тесты на основные сценарии (allowed transitions, ABAC denied, status mismatch)

Всё с правильными импортами, аннотациями, обработкой исключений по методологии.

Что делать дальше

Прочитать ответ внимательно (не пропустить важные детали)
Применить через Claude Code Edit-tools (или скопировать руками)
Запустить /ucp-pattern-review на свежий diff — получить замечания если что-то не по правилам
Запустить тесты локально, поправить если что-то падает
PR

Реальное время от запроса до закоммиченного кода — 5–10 минут. Из них 3 на работу скилла, остальное на чтение и применение.

Все скиллы для маленьких задач

Под разные типы операций — разные ucp-*-design:

Что нужно	Какой скилл
UseCase + Handler + контроллер	`ucp-pattern-design`
REST API контракт (OpenAPI)	`ucp-api-design`
Доменный агрегат + события (Tier C)	`ucp-ddd-tactical-design`
Spring Security + JWT + ABAC	`ucp-auth-design`
Тесты на UseCase / business rule	`ucp-test-design`

И симметричные *-review для проверки существующего кода.

Сценарий 2: целый сервис от спеки до прода

Здесь от вас бизнес-описание (даже на одну страницу), а на выходе — рабочий сервис. Нужны все три компонента стека: usecase-pattern-skills, superpowers, желательно context7.

Полный pipeline за 4 шага.

Шаг 1. Спека из бизнес-описания

/ucp-spec-design Сервис каталога маркетплейса. Продавец публикует и скрывает товары, Order Service берёт цену по productId. Tier B

Скилл читает описание, определяет нужный Tier (A — legacy/слоистая, B — UCP с CQRS, C — DDD/Hexagonal) и создаёт спеку из 16 разделов в docs/spec/:

docs/spec/
  01-context.md           — Bounded Context, scope, не-scope
  02-language.md          — Глоссарий, Ubiquitous Language
  03-model.md             — ER-схема + UseCase-модели
  04-lifecycle.md         — State machines
  05-roles.md             — Роли и права (RBAC + ABAC)
  06-rules.md             — Бизнес-правила
  07-commands.md          — Commands (UseCase'ы)
  09-queries.md           — Queries
  10-use-cases.md         — Use cases в нотации UC-N
  11-ui.md                — Что нужно от backend для UI
  13-errors.md            — Каталог ошибок (RFC 9457)
  14-integrations.md      — Inbound/outbound REST, Kafka
  15-acceptance.md        — Критерии приёмки (AC-N)
  16-nfr.md               — НФТ (производительность, безопасность, эксплуатация)
  17-stack.md             — Стек технологий
  catalog-service.md      — Консолидированная версия

Для Tier B пропускаются §8 events и §12 sagas (они появляются в Tier C).

С context7 версии библиотек в спеке актуальные. С superpowers — внутреннее планирование, проще не пропустить раздел.

Шаг 2. План реализации

/superpowers:writing-plans

Читает спеку, производит план шагов:

1. scaffold gradle multi-module
2. Liquibase migration v-1.0/initial-schema.yaml
3. jOOQ codegen из applied-схемы
4. ProductRepository — jOOQ generated POJO + DSL
5. CreateProductUseCase + Handler + контроллер
6. PublishProductUseCase + Handler
7. HideProductUseCase + Handler
8. GET /products/{id} query
9. SecurityConfig (3 профиля: prod, local, integration-test)
10. Integration tests на каждый UC + AC из спеки
11. ArchUnit тесты на инварианты слоёв

Каждый шаг с критериями приёмки. План остаётся в контексте сессии — executing-plans будет идти по нему.

Шаг 3. Исполнение

/superpowers:executing-plans

Идёт по плану шаг за шагом. На каждом вызывает соответствующий ucp-*-design:

Шаг	Скилл
Bootstrap (gradle, профили, Liquibase, jOOQ)	`ucp-bootstrap-design`
Доменные классы (Tier C)	`ucp-ddd-tactical-design`
UseCase + Handler + контроллер	`ucp-pattern-design`
Spring Security	`ucp-auth-design`
API + ProblemDetails	`ucp-api-design`
Тесты	`ucp-test-design`

После каждого шага — superpowers:verification-before-completion: gradle compileJava, gradle test. Не зелёное — не двигаемся дальше.

Шаг 4. Финальный разбор

/ucp-pattern-review
/ucp-api-review
/ucp-ddd-tactical-review
/ucp-java-style-review
/ucp-auth-review

Каждый скилл методологии прогоняется по diff. Замечания цитируют код правила (R-7, JS-2.5, BR-C5).

И финальный внешний взгляд:

/superpowers:requesting-code-review

Subagent-ревьюер читает PR с позиции «не знаком с кодом, но знаком с UCP» и оставляет комментарии о неочевидных моментах, что разработчик упустил из-за привычности.

Реальное время

От бизнес-описания до работающего сервиса — день-два, если стек установлен. Без AI и методологии — недели на ту же постановку. Это и есть множитель производительности, про который много говорят, но без явного workflow он остаётся лозунгом.

Когда какой сценарий выбирать

Сколько у вас задача?
│
├─ Одна операция в существующем сервисе
│  → Сценарий 1 (один UseCase, 3 минуты)
│  → ucp-pattern-design / ucp-api-design напрямую
│
├─ Новый модуль (3-5 операций)
│  → Сценарий 1 повторяется N раз
│  → По одному UseCase за итерацию
│  → Не нужен superpowers, ритм быстрый
│
├─ Новый сервис с нуля
│  → Сценарий 2 целиком
│  → Все три компонента стека
│
├─ Переписывание существующего сервиса с легаси на UCP
│  → Сначала аудит (ucp-pattern-review на текущий код)
│  → Потом migration plan через superpowers:writing-plans
│  → Дальше Сценарий 2 по модулям
│
└─ Сложный архитектурный выбор (saga vs 2PC, ивенты ли вообще)
   → superpowers:brainstorming
   → дальше Сценарий 2 с уже определённым подходом

Хорошие практики

Стартовать с Tier ниже, чем кажется нужным. Если сомневаетесь, B или C — берите B. Tier повышается легко, понижается тяжело. Не стройте Hexagonal где хватит UseCase Pattern.

Пропускать verification-before-completion нельзя. Соблазн «потом проверим» большой, особенно когда AI сделал что-то выглядящее правильным. Не зелёный билд после шага = плохой шаг, возвращайтесь.

Один UC = один PR. Не сваливать 5 UseCase-ов в один коммит, даже если AI пишет быстро. Размер PR определяет качество ревью.

Спека и код должны совпадать. Изменили UseCase в коде — обновите раздел 7 спеки в том же PR. Расхождение = баг, не «доработаем потом». На этом ломаются 80% методологий.

AI-скиллы для ревью идут перед человеком, не вместо. /ucp-*-review ловит банальные нарушения правил, человек смотрит на архитектуру и trade-off-ы. Если человек ушёл из цикла полностью — это уже multi-agent (см. ниже про антипаттерны).

Антипаттерны

«Создадим только спеку, код потом» — спека без кода устаревает за 2 недели. Делайте параллельно или удаляйте спеку.

«AI заодно отрефакторил три соседних модуля» — узкие промпты дают узкий diff. «Заодно» = разраставшийся PR, который никто не успевает проверить.

«У нас Tier C везде потому что DDD» — Tier C дороже B и сложнее в поддержке. Применяйте только там, где есть инварианты в домене (Order, Payment, Reservation). Справочники и админки — Tier A или B.

«AI написал тесты, я не читал» — тесты-«обёртки» (assertNotNull, verify(any())) пропускают баги. Прочитайте 5 тестов, поймёте качество остальных.

«Skills + multi-agent с ролями = ещё круче» — нет. Подробно Skills vs multi-agent в статье про установку. Multi-agent с автономным диалогом ломает voice consistency и audit trail.

Что дальше

Скиллы UCP — каталог и установка — если ещё не настроили инструменты
Use Case спецификация: универсальный шаблон — что в каждом из 16 разделов
Уровень 1 — стартовый → 2 → 3 → 4 — выбор уровня зрелости
Кейс: Order Service (Tier C) — полный пример сервиса с применением UCP
Если внедряете в команде — внедрение Use Case Pattern

Обсудить применение →

← Предыдущая

Методология и AI

Ревью AI-кода