Как спроектировать модуль с нуля? Пошаговый подход.

Проектирование модуля с нуля – системный процесс, начинающийся с бизнес-требований и заканчивающийся техническим дизайном. Этот вопрос часто задают на собеседованиях уровня Middle/Senior.

Шаг 1. Понять бизнес-требования

• Какую проблему решает модуль?
• Кто пользователь (другой сервис, оператор, клиент)?
• Какие бизнес-правила и ограничения?

Шаг 2. Определить границы модуля (Bounded Context)

• Какие сущности входят?
• Какие данные принадлежат модулю, а какие – соседнему?
• Ubiquitous Language – согласовать термины с бизнесом. Если бизнес говорит “лимит”, а разработчики “ограничение” – будут недоразумения.

Шаг 3. Определить API (контракт)

• Входящие API (REST, gRPC, Message Listener).
• Исходящие интеграции (другие модули, внешние системы).
• Формат данных (DTO, Events).

Шаг 4. Выбрать архитектуру модуля

Простой CRUD-модуль:          Сложная бизнес-логика:
  Controller                    Controller (Adapter In)
  → Service                     → Use Case (Port In)
  → Repository                  → Domain Model
  → Entity                      → Repository (Port Out)
                                → Adapter Out (JPA, Kafka)

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

Шаг 5. Спроектировать доменную модель

• Выделить Entity и Value Objects.
• Определить Aggregates и их границы.
• Определить доменные события.

Шаг 6. Определить нефункциональные требования

• Производительность (RPS, latency).
• Доступность (SLA).
• Безопасность (авторизация, аудит).

Шаг 7. Спроектировать хранение данных

• Выбор БД (PostgreSQL, MongoDB, Redis).
• Схема данных, индексы.
• Кэширование.

Шаг 8. Спроектировать обработку ошибок

• Retry-стратегия.
• Fallback-поведение.
• Dead Letter Queue для необработанных сообщений.

Пример: модуль “Лимиты операций”

Bounded Context: Лимиты
Entities: OperationLimit, LimitRule
Value Objects: Money, Period

API:
  POST /api/limits          — создать лимит
  GET  /api/limits/{id}     — получить лимит
  POST /api/limits/check    — проверить операцию на лимит

Events:
  LimitExceededEvent → уведомление клиенту
  LimitUpdatedEvent  → обновление кэша

Хранение: PostgreSQL (лимиты) + Redis (кэш текущих остатков)

NFR: latency < 50ms (проверка лимита на hot-path платежа)

Итог

Ключ к хорошему проектированию – начинать с бизнеса, а не с технологий. Сначала поймите, что делает модуль и кто его использует. Технический дизайн вытекает из требований. Если на собеседовании вы начнёте ответ с “возьмём Spring Boot и PostgreSQL” – это красный флаг. Начните с бизнес-требований и границ.

На собеседовании: Интервьюер оценивает системность мышления: от бизнеса к техническим решениям, а не наоборот. Частая ошибка – сразу погружаться в выбор технологий, не определив границы модуля и бизнес-правила.