Программа

Программа подготовки backend-разработчика в команде Use Case Pattern (backend-трек, Java-биндинг): фазы от методологии и уровней зрелости через Spring, данные, DDD, паттерны, брокеры — до сквозного кейса маркетплейса.

Этот сайт устроен как программа подготовки. Каждая статья — кусочек знаний, необходимый, чтобы работать в команде, использующей Use Case Pattern. Программа разбита на шестнадцать фаз: от методологии и архитектурных решений через фундамент Spring, принципы и паттерны проектирования, данные, поиск, object storage, аналитику, паттерны, брокеры — до сквозного кейса маркетплейса.

Программа описывает backend-трек на Java-биндинге. Концептуальные фазы — методология, уровни зрелости, DDD, данные, паттерны, брокеры — общие для всех языков; инструментальные (Spring, jOOQ) — специфика Java. Python-биндинг этих же контрактов живёт в репозитории скиллов.

Можно читать подряд (рекомендуется новым в стеке) или точечно (если интересует конкретная тема). К концу программы у вас сложится связная картина того, как UCP-сервис устроен изнутри и снаружи.

Фаза 1. Use Case Pattern: методология

Зачем эта фаза. Понять центральную идею: что такое UCP, почему она нужна команде с AI, чем отличается от Clean Architecture и DDD.

Use Case Pattern (обзор)
Как применять: пошаговый гид
Настройка Claude Code под UCP — каталог и установка скиллов
Use Case спецификация: шаблон
Уровни зрелости: 0 As-is, 1 Слоёный, 2 UCP, 3 DDD+Hexagonal

Фаза 2. Три уровня зрелости

Зачем эта фаза. Уметь выбирать уровень под задачу — не строить Hexagonal там, где хватит MVP.

Фаза 3. Архитектурный выбор и системный дизайн

Зачем эта фаза. До того, как писать код: как проектировать систему по методу, какие развилки решать и как описывать результат диаграммами.

Фаза 4. Spring как фундамент

Зачем эта фаза. UCP-сервисы строятся на Spring/Spring Boot. Без понимания DI, lifecycle, транзакций, AOP — нельзя осознанно писать Handler-ы и интегрировать инфраструктуру.

Фаза 5. Принципы и паттерны проектирования

Зачем эта фаза. Handler-ы, агрегаты, порты и адаптеры — это классы; SOLID и паттерны GoF — словарь, на котором они проектируются. Spring сам построен на этих принципах — без них фреймворком пользуются вслепую.

Фаза 6. Данные: PostgreSQL, MongoDB, jOOQ

Зачем эта фаза. Persistence-слой — больше половины проблем UCP-сервиса. ACID, изоляция, индексы, миграции, моделирование — must-know для уровня senior.

ACID и уровни изоляции в PostgreSQL
Размер БД, партиционирование и шардирование в PostgreSQL
ACID, read/write concerns, транзакции в MongoDB
Репликация и шардинг в MongoDB
Моделирование документов в MongoDB
PostgreSQL Style Guide — правила в Java/Spring
jOOQ Style Guide — persistence в UCP-стеке

Фаза 7. Поиск: Elasticsearch

Зачем эта фаза. ES — стандартный движок для полнотекстового поиска, фасетов и near-real-time аналитики в UCP-сервисах. Когда WHERE name ILIKE '%q%' в Postgres тормозит, или нужны весовые ranking-запросы — это сюда.

Fundamentals: inverted index, cluster, shards, mapping, analyzers
Query DSL и relevance scoring — match/term/bool, BM25, фасеты
Spring Data Elasticsearch: клиент, репозитории, индексация, CDC
Operations: ILM, snapshots, hot/warm/cold, sizing, мониторинг

Фаза 8. Object storage (S3)

Зачем эта фаза. S3-совместимое хранилище — третий тип storage в UCP-стеке (после реляционной и документной БД): для пользовательских файлов, бэкапов, экспортов, статики. Senior должен понимать различие моделей и сочетать их правильно.

Фаза 9. Аналитика: ClickHouse

Зачем эта фаза. Аналитические запросы по миллионам событий душат прод-PostgreSQL. ClickHouse — четвёртый тип хранилища в стеке (OLTP → поиск → файлы → OLAP): события, аудит, метрики продукта, отчёты.

Фаза 10. Domain-Driven Design

Зачем эта фаза. UCP уровня 3+ опирается на DDD: агрегаты, доменные события, bounded context. Без этого Handler становится сервисной свалкой.

Что такое DDD и зачем он нужен
Стратегические паттерны — Bounded Context, Context Map
Тактические паттерны — Entity, Value Object, Aggregate
Интеграционные паттерны — ACL, OHS
Принципы проектирования
DDD Tactical Style Guide — 58 правил R-ENT/R-VO/R-AGG/...

Фаза 11. Архитектурные паттерны сервиса

Зачем эта фаза. CQRS — опция Уровня 2, Hexagonal — часть Уровня 3; два паттерна, к которым команда приходит по мере роста зрелости. Парные style-guides — правила для AI-ревью.

Фаза 12. Брокеры и распределённые системы

Зачем эта фаза. Между сервисами — Kafka и/или RabbitMQ. Между БД и брокером — saga, outbox, idempotency. Без этого распределённый сервис теряет данные на первом сбое.

Фаза 13. API, безопасность, микросервисы

Зачем эта фаза. Внешняя поверхность сервиса: REST-контракты, OAuth2/JWT, структурная организация микросервисов.

Фаза 14. Инфраструктура и доставка

Зачем эта фаза. Среда исполнения и путь до прода: Kubernetes, облако и конвейер доставки. Probes, ресурсы JVM, IAM, managed-данные, quality gates и стратегии релиза — ответственность разработчика, не только платформы.

Фаза 15. Качество, тесты, эксплуатация

Зачем эта фаза. Сервис, который нельзя поддерживать, — не работа. Кодстандарт, тестовая стратегия, observability, AI как часть процесса ревью.

Java Style Guide — кодовый стандарт команды
Test Strategy Style Guide — пирамида тестов
Spring Testing: слайсы, TestContainers
Spring Actuator, Micrometer, трейсинг
Observability Style Guide
AI пишет код. Зачем тогда методология?
Как ревьюить код, который написал AI
Executable engineering standard

Фаза 16. Применение на сквозном кейсе

Зачем эта фаза. Связать всё вместе на одном бизнес-домене — маркетплейс. От бизнес-брифа через карту сервисов до полной спеки Уровня 3 и кода.

Дальше

Главная страница — обзор методологии и услуг.
Каталог стандартов — все 17 style guides с правилами R-* для AI-ревью.
Use Case Pattern (обзор) — если ещё не читали — лучшая точка входа.
Услуги — если решили внедрять методологию и нужна помощь.