С чего начать разработку сервиса для создания пользователя и получения счетов
Что проверяют
Идёте ли вы от контракта и данных или сразу пишете контроллер. Задача намеренно расплывчатая: смотрят, какие вопросы вы зададите до кода и что вспомните про деньги, транзакции и ошибки.
Как отвечать
Начните с уточнений: что считается счётом и кто его владелец, бывает ли несколько счетов и валют, нужна ли идемпотентность создания пользователя, какие ожидаются объёмы, кто потребитель API, требуется ли аудит операций.
Затем контракт. POST /users отвечает 201 и ссылкой на созданный ресурс, GET /users/{id}/accounts отдаёт список с пагинацией. Наружу уходят отдельные DTO, а не сущности. Ошибки описываются единообразно: код, машинночитаемый признак, понятное сообщение.
Модель и хранение: уникальность почты обеспечивается индексом в базе, а не только проверкой в коде, миграции через Liquibase или Flyway заводятся с первого коммита, суммы хранятся в BigDecimal с явной валютой, числа с плавающей точкой для денег исключены.
Слои: контроллер без логики, сервис с границей транзакции, репозиторий. Валидация через Bean Validation, единая обработка ошибок в @RestControllerAdvice. Пароль только в виде хеша, доступ закрывается Spring Security.
Тесты закладываются сразу: слайс-тест веб-слоя и интеграционный с поднятой базой через Testcontainers. Плюс логи с идентификатором запроса и метрики, иначе первый же инцидент придётся разбирать вслепую.
Где спотыкаются
Отдают JPA-сущность прямо из контроллера. Наружу утекают лишние поля, а ленивые связи превращаются в LazyInitializationException при сериализации.
Полагаются на автоматическое обновление схемы вместо миграций. Стенды расходятся между собой, а откатить изменение нечем.
Делают создание пользователя неидемпотентным. Повтор запроса по таймауту создаёт дубль, и без уникального индекса и осмысленного ответа на конфликт база быстро набирает мусор.