Как устроена архитектура приложения: клиент, сервер, бизнес-логика, база данных
Что проверяют
Понимаете ли вы путь запроса от нажатия кнопки до записи в базу настолько, чтобы писать требования, по которым разработчик не будет гадать. Следом обычно просят нарисовать sequence-диаграмму конкретной операции или спрашивают, где должна жить конкретная проверка.
Как отвечать
Пройдите по слоям и для каждого скажите, что аналитик про него фиксирует:
- клиент: веб или мобильное приложение. Показывает данные, собирает ввод, делает удобную валидацию (формат телефона, обязательные поля). В требованиях: экранные формы, состояния, тексты ошибок;
- API: контракт между клиентом и сервером, обычно REST поверх HTTP с JSON, реже gRPC или GraphQL. Аналитик описывает методы, поля и коды ответов, чаще всего в OpenAPI;
- сервер и бизнес-логика: правила предметной области (расчёт скидки, смена статуса заказа, права доступа). Живут на сервере, потому что клиенту доверять нельзя: запрос можно отправить в обход интерфейса;
- база данных: хранение и целостность, то есть ограничения, связи, транзакции. Артефакт аналитика: ER-диаграмма и описание сущностей.
Покажите поток на примере. Пользователь оформляет заказ, клиент шлёт POST /orders, сервер проверяет остатки и лимиты, в одной транзакции создаёт заказ и резервирует товар, возвращает 201 с номером, клиент показывает подтверждение. Такой поток удобно рисовать sequence-диаграммой в PlantUML, а общую картину системы в нотации C4.
Добавьте про интеграции: синхронный вызов, когда ответ нужен сразу, и очередь (Kafka, RabbitMQ), когда операцию можно выполнить позже, например отправку уведомлений.
Где спотыкаются
Считают валидацию на клиенте достаточной. Это удобство, а не защита, и требование «проверить на форме» без серверной проверки оставляет дыру.
Размазывают бизнес-правило по слоям: половина расчёта в интерфейсе, половина в хранимой процедуре. Правило описывают в одном месте и явно указывают, где оно исполняется.
Описывают только успешный сценарий. Разработчику нужно знать, что делать при таймауте, повторной отправке формы и конфликте данных, иначе эти решения примут за вас.