← назад к разделу

Чаще всего вопрос звучит так: «Понятно, что такое Use Case Pattern — но с чего начать прямо сейчас?». Эта статья отвечает именно на него: два конкретных сценария, команды, ожидаемые результаты и частые ошибки.

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

Когда задача маленькая: одна операция в существующем сервисе

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

Здесь нужен единственный скилл: открываете Claude Code в проекте и вызываете:

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

Через 30–60 секунд скилл вернёт:

  • CancelOrderUseCase — объект команды с описанием входных данных и ожидаемого результата;
  • CancelOrderHandler — компонент с транзакционной семантикой; бизнес-логика проверки статуса и прав — внутри;
  • контроллер с авторизацией, реализующий OpenAPI-интерфейс;
  • тесты на основные сценарии (разрешённые переходы, отказ по правам, несоответствие статуса).

Дальше:

  1. Читаете ответ внимательно.
  2. Применяете через инструменты редактирования Claude Code (или копируете вручную).
  3. Запускаете /ucp-pattern-review на свежий diff — получаете замечания, если что-то не по правилам.
  4. Запускаете тесты, правите если что-то красное.
  5. Создаёте PR.

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

Таблица скиллов для маленьких задач

Под разные типы операций — разные скиллы:

Что нужноКакой скилл
UseCase + Handler + контроллерucp-pattern-design
REST API контракт (OpenAPI)ucp-api-design
Доменный агрегат + события (Уровень 3)ucp-ddd-tactical-design
Аутентификация + авторизацияucp-auth-design
Тесты на UseCase и бизнес-правилаucp-test-design

Для каждого design-скилла есть парный *-review — для проверки уже написанного кода.

Когда задача большая: новый сервис с нуля

Здесь на входе — бизнес-описание (хотя бы на страницу), на выходе — рабочий сервис. Процесс состоит из четырёх шагов.

Шаг 1. Написать спеку из бизнес-описания

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

Скилл читает описание и создаёт спецификацию в docs/spec/: корневой файл контекста и по файлу на каждый домен-юнит в aggregates/.

Если сервис уже существует, а описания нет — стартуйте с /ucp-spec-tier-0. Он читает код, миграции и конфигурацию и создаёт as-is спеку в том же формате. Это отправная точка для последующего улучшения.

Шаг 2. Составить план реализации

/superpowers:writing-plans

Скилл читает спеку и производит пронумерованный план шагов — каждый с критериями приёмки. Например:

1. Scaffold проекта (модули, сборка, профили)
2. Миграция схемы БД: initial-schema
3. Кодогенерация из применённой схемы
4. ProductRepository — доступ к данным
5. CreateProductUseCase + Handler + контроллер
6. PublishProductUseCase + Handler
7. HideProductUseCase + Handler
8. GET /products/{id} — запрос
9. Конфигурация безопасности (prod / local / integration-test)
10. Интеграционные тесты на каждый UseCase
11. Архитектурные тесты на инварианты слоёв

Шаг 3. Выполнить план

/superpowers:executing-plans

Скилл идёт по плану шаг за шагом и на каждом вызывает нужный ucp-*-design:

ШагСкилл
Сборка, профили, миграции, кодогенерацияucp-bootstrap-design
Доменные классы (Уровень 3)ucp-ddd-tactical-design
UseCase + Handler + контроллерucp-pattern-design
Аутентификация и авторизацияucp-auth-design
API + обработка ошибокucp-api-design
Тестыucp-test-design

После каждого шага — проверка: сборка + тесты зелёные, прежде чем переходить к следующему шагу.

Шаг 4. Финальное ревью

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

Каждый скилл методологии проходится по diff. Замечания ссылаются на конкретные коды правил. После — внешний взгляд через /superpowers:requesting-code-review: ревьюер смотрит на PR со стороны, замечает то, что привычный взгляд пропускает.

От бизнес-описания до работающего сервиса — день-два, если стек установлен.

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

Простое правило:

  • Одна операция в существующем сервисе → один ucp-*-design скилл напрямую.
  • Несколько операций в существующем сервисе → первый сценарий повторяется по одной операции за итерацию, без superpowers.
  • Новый сервис с нуля → второй сценарий целиком.
  • Переписать существующий сервис → сначала ucp-pattern-review на текущий код (понять, что не так), потом план миграции через superpowers:writing-plans, потом второй сценарий по модулям.
  • Неясен сам подход → /superpowers:brainstorming, потом второй сценарий с уже определённым решением.

Что стоит делать

Стартуйте с уровня ниже, чем кажется нужным. Если сомневаетесь между Уровнем 2 и 3 — берите 2. Уровень повышается легко, понижается тяжело. DDD и Hexagonal нужны там, где в домене есть сложные инварианты (заказ, платёж, бронирование). Справочники и административные страницы — Уровень 1 или 2.

Не пропускайте проверку после каждого шага. Когда AI генерирует что-то выглядящее правильным, соблазн пропустить проверку велик. Незелёный билд после шага — это сигнал, что шаг плохой, и нужно вернуться.

Один UseCase — один PR. Не складывайте пять операций в один коммит, даже если AI пишет их быстро. Размер PR прямо влияет на качество ревью.

Держите спеку и код в синхронизации. Изменили UseCase в коде — обновите спеку в том же PR. Расхождение — это ошибка, а не «доработаем потом».

Скиллы для ревью идут перед человеком, а не вместо. ucp-*-review ловит нарушения правил, человек смотрит на архитектуру и компромиссы.

Чего избегать

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

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

«У нас везде Уровень 3, потому что мы делаем DDD» — Уровень 3 дороже в поддержке. Используйте его только там, где в домене есть реальные инварианты.

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

«Скиллы плюс команда агентов с ролями — ещё лучше» — нет. Несколько агентов в автономном диалоге ломают согласованность стиля и журнал аудита. Подробнее — в статье про установку скиллов.

Коротко

  • Одна операция → один ucp-pattern-design напрямую, результат за несколько минут.
  • Новый сервис → ucp-spec-design → план → executing-plans → финальные ревью.
  • Стартуйте с уровня ниже, чем кажется нужным: Уровень 2 вместо 3, если нет сложных инвариантов.
  • Один UseCase — один PR. Один шаг — зелёный билд перед следующим.
  • Спека и код должны совпадать: изменился UseCase — обновите спеку в том же PR.
  • Скиллы ревью дополняют человека, а не заменяют его.

Что почитать дальше

  • Скиллы UCP — каталог и установка — если ещё не настроили инструменты.
  • Use Case спецификация: универсальный шаблон — корень контекста и домен-юниты.
  • Уровни зрелости: 1 — Слоёный → 2 — Use Case Pattern → 3 — DDD + Hexagonal.
  • Кейс: Order Service (Уровень 3) — полный пример сервиса с применением UCP.