В чём специфика проектов без интерфейсов
Backend-only проект — это система без собственного пользовательского интерфейса, которая взаимодействует с другими сервисами, а не напрямую с конечным пользователем. Здесь «интерфейсом» становится контракт, а пользователем выступают другие сервисы, приложения или внешние системы. Такой проект может быть компонентом большой архитектуры или самостоятельным продуктом, предоставляющим API.
Чаще всего архитектура подобных проектов представляет собой:
- микросервисы внутри распределенной системы, которые реализуют конкретную бизнес-логику и обмениваются данными через HTTP, gRPC или очереди сообщений;
- интеграционные сервисы и шлюзы, которые связывают разные системы между собой, маппят форматы данных и обеспечивают маршрутизацию запросов;
- дата-платформы и сервисы обработки данных, где ключевая задача — прием, трансформация, агрегация и хранение информации;
- API-first продукты, в которых ключевым элементом становится внешний контракт: мобильные приложения, веб-клиенты и партнерские системы взаимодействуют с продуктом исключительно через опубликованный и формализованный API.
Отличия от проектов с UI: кто пользователь, если нет интерфейса?
В проектах с интерфейсом работа системы более предсказуемая и наглядная: пользователь — это человек, описывается его сценарий, шаги, ожидания, поведение при ошибке. Аналитика строится вокруг взаимодействия человека с системой: что он видит, что нажимает, что происходит после, учитываются особенности пользовательского поведения. Отсюда даже есть отдельный раздел UX/UI — дизайна, отвечающего за пользовательский опыт и визуал, создание сценариев, прототипирование, тестирование, проектирование структуры: как продукт работает и выглядит, насколько легко достичь цели.
В backend-only проекте пользователем является другой сервис. Это может быть мобильное приложение, BFF, фронтенд, внешняя система, внутренний микросервис или batch-процесс. С точки зрения системы именно он инициирует действия, отправляет данные, получает ответы и ожидает определенного поведения в соответствии с API-контрактом, изменение которого может затронуть несколько зависимых сервисов.
Поведение системы определяется строго контрактом: форматом запроса, структурой ответа, кодами ошибок, правилами валидации. Если контракт описан неточно и реализован некорректно, сервис-потребитель не сможет корректно интерпретировать ответы или гарантии системы.
Потенциальная ошибка распространяется по цепочке интеграций, поэтому одна из задач аналитика в backend-only проекте — описать взаимодействие так, чтобы сервис-потребитель мог однозначно интерпретировать контракт, а команда разработки понимала, какие гарантии система обязана обеспечивать.
Что именно описывает аналитик в backend-only проекте
В проектах без интерфейса аналитик работает не с экранами и пользовательскими сценариями, а с поведением системы как совокупности сервисов, контрактов и правил взаимодействия. В этом случае ключевым артефактом становится спецификация интеграционного взаимодействия: какие данные система принимает, какие возвращает, при каких условиях выполняются операции и какие гарантии она обеспечивает другим сервисам.
Чтобы понять, как именно строится такая работа, разберем основные блоки, которые аналитик описывает в backend-only проекте.
API-контракты
В backend-only проекте API становится фактической точкой входа в систему — именно через него другие сервисы взаимодействуют с бизнес-логикой.
Здесь важно понимать, что существует два подхода к работе с API: API-first и code-first.
В API-first подходе контракт проектируется заранее: сначала описывается спецификация (например, в формате OpenAPI), она согласовывается с командами и только после этого начинается реализация. Аналитик активно участвует в формировании структуры API, потому что именно спецификация становится основой для разработки.
В code-first подходе разработчики сначала реализуют эндпоинты в коде, а спецификация генерируется автоматически, на основе аннотаций и моделей. Здесь роль аналитика смещается в сторону проверки и согласования уже реализованного контракта, чтобы он соответствовал бизнес-логике и интеграционным требованиям.
Аналитик при проработке API-контрактов фиксирует:
- перечень доступных методов и точек доступа;
- список операций и соответствующих им маршрутов;
- структуру входных и выходных данных;
- обязательность и типы полей;
- ограничения (длины строк, допустимые значения, форматы);
- коды ответов и формат ошибок;
- правила валидации;
- поведение при повторном запросе;
- версионирование.
Типичной ошибкой может стать описание только happy path. Например, если не зафиксировать, что происходит при тайм-ауте или частичном сбое, разработчики могут по-разному интерпретировать логику: один добавит ретраи, другой — нет, третий вернет ошибку пользователю, из-за чего поведение системы становится непредсказуемым.
Параллельно аналитик готовит таблицу маппинга полей, если нужно сопоставить внутренние сущности с форматом внешней системы, отдельно описывает формат ошибок: какие коды возвращаются, что приходит в теле ответа и в каких случаях. При необходимости фиксирует правила версионирования и добавляет примеры запросов и ответов — как для успешного сценария, так и для типовых ошибок.
Для проектирования, редактирования и документирования API на основе спецификации OpenAPI обычно используют инструмент Swagger Editor, для тестирования запросов — Postman, спецификация хранится в Confluence (или в какой-то другой вики-системе) или репозитории вместе с кодом. В contract-first подходе спецификацию могут передавать в OpenAPI Generator, чтобы на ее основе создавать заготовки серверной части или клиентские библиотеки. А для формализации структуры данных дополнительно применяют JSON Schema, чтобы контракт был не просто понятным, а еще и проверяемым.
Интеграционные сценарии
Большинство проблем backend-only проектов возникают на стыке систем, поэтому аналитик должен описывать не только отдельный метод, но и сценарий интеграционного взаимодействия.
Здесь часто используются sequence-диаграммы или BPMN, потому что в тексте сложно удержать сложную цепочку вызовов — диаграмма же позволяет наглядно отследить, кто инициирует взаимодействие, в каком порядке идут вызовы, где происходит смена статусов, какие ветки возможны при ошибке. Это помогает зафиксировать не только основной сценарий, но и альтернативные ветки, а также:
- кто инициирует запрос;
- синхронное или асинхронное взаимодействие;
- используется ли очередь;
- есть ли ретраи и по каким правилам;
- что происходит при тайм-ауте;
- как обрабатываются частичные сбои;
- где хранится статус операции.
О том, как создавать sequence-диаграммы с помощью кода в PlantUML, я рассказывала ранее. Кроме того, есть визуальный инструмент, с помощью которого можно создавать диаграммы последовательности, — «рисовалки» с примитивным интерфейсом по типу draw.io или чуть более приятная по визуалу Miro, но эти способы, на мой взгляд, менее удобные с точки зрения поддержки диаграмм.
Для создания BPMN можно использовать такие инструменты, как Camunda Modeler.
Модель данных
В backend-only проекте модель данных становится одной из самых критичных частей аналитики. Если в UI-проекте ошибку в логике можно временно «прикрыть» интерфейсным решением (например, задизейблить временно кнопку или не отображать статус на экране), то ошибка в структуре данных быстро превращается в системную проблему: меняются контракты, ломаются интеграции, усложняется миграция, накапливается технический долг. Например, в одном проекте поле createdAt было описано просто как «дата создания», без указания формата. При подключении внешнего партнера выяснилось, что один сервис отправляет ISO-строку, а второй ожидает timestamp, из-за чего начались ошибки валидации и расхождения в отчетах. В итоге из-за одной незафиксированной детали пришлось версионировать API и менять контракт.
При работе с моделью данных задача аналитика — продумать, как система будет хранить, изменять и передавать информацию на протяжении всего жизненного цикла сущностей.
Аналитик обычно фиксирует:
- ключевые сущности системы и их атрибуты;
- связи между сущностями;
- обязательность и ограничения полей;
- уникальность и идентификаторы;
- статусные модели и допустимые переходы;
- правила изменения и удаления данных;
- требования к историчности и аудиту.
На практике это выливается в конкретные артефакты. Чаще всего при проектировании реляционных баз данных для отображения сущностей, атрибутов и взаимосвязей аналитик готовит ERD-диаграмму, которая визуально показывает структуру и связи. Дополнительно формирует описание в виде таблиц, словарь данных — текстовый документ, где расшифровывает каждое поле: его назначение, формат, источник, правила заполнения.
Для быстрой визуализации структуры можно использовать draw.io или dbdiagram.io — достаточно простой в освоении и интуитивный онлайн-сервис, который позволяет строить ERD прямо из текстового описания. О том, как им пользоваться, я рассказывала здесь.
Отдельное внимание необходимо уделять проработке статусной модели, потому что, если переходы между статусами не продуманы заранее, система начинает вести себя непредсказуемо. Именно поэтому аналитик предварительно описывает, какие переходы между состояниями допустимы, при каких условиях они происходят и какие ограничения должны соблюдаться, а разработчики уже воплощают эту логику в коде.
При этом не всё в backend-only проекте можно предусмотреть на этапе аналитики, особенно когда система начинает жить под реальной нагрузкой. Был кейс, когда сервис расчета лимитов корректно спроектировали и согласовали, определили, что лимит рассчитывался на основе набора параметров клиента, исторических данных и текущего статуса договора. После запуска выяснилось, что в реальности партнеры отправляют запросы неравномерно: в определенные часы нагрузка возрастала в десятки раз, причем многие запросы относились к одним и тем же клиентам. Сервис пересчитывал лимит каждый раз заново, потому что по бизнес-логике расчет зависел от актуального состояния, что привело к блокировкам базы и тайм-аутам на пиковых нагрузках, хотя формально требования были выполнены.
Как аналитик описывает нефункциональные требования
Роль аналитика при работе с нефункциональными требованиями в backend-only проектах специфична, поскольку он не может самостоятельно определить, сколько запросов в секунду выдержит система или какое SLA должно быть у сервиса. В данном случае это уже зона ответственности разработчиков и архитектора: они лучше понимают ограничения инфраструктуры и последствия технических решений.
Аналитик же может зафиксировать ожидания со стороны бизнеса, обозначить рамки, например:
- сколько пользователей или систем будут обращаться к сервису в тот или иной период;
- какие операции критичны по времени отклика;
- какие существуют ограничения, периоды обслуживания;
- допустим ли простой и на какой срок;
- насколько важна целостность данных;
- есть ли требования к хранению и аудиту.
В этом случае аналитик не формулирует точные цифры, скорее обозначает контекст, который в дальнейшем обсуждается вместе с разработчиком. Например, если бизнес-заказчик говорит, что подтверждение операции должно происходить «почти мгновенно», аналитик может уточнить, что считается допустимым — одна секунда или пять? Можно ли обрабатывать часть сценариев асинхронно? Нужен ли механизм повторного выполнения операции? То есть задать как можно больше уточняющих вопросов и вынести обсуждение в совместную проработку с технической командой.
Если в проектах с интерфейсом часть нефункциональных требований аналитик действительно может описывать более подробно самостоятельно (удобство использования, локализация, адаптивность, поведение при ошибках на экране), поскольку опять же это ближе к UX и пользовательскому опыту, то что касается критериев, определяющих, как именно система должна работать для backend-сервиса (требования к нагрузке, производительности, масштабируемости, безопасности), почти всегда формируется совместно с технической командой. Аналитик задает направление и фиксирует договоренности, разработчик и архитектор уточняют ограничения и способы реализации.
Сопровождение и мониторинг готового продукта
Важно сказать, что backend-only проект не заканчивается на этапе описания API и интеграций: после запуска начинается сопровождение — менее заметная, но такая же важная часть работы. Роль аналитика состоит в поддержании порядка в уже существующей системе, например, он:
- ведет реестр требований и следит за их актуальностью;
- поддерживает roadmap будущих доработок, чтобы команда понимала, куда движется продукт;
- фиксирует технический долг с привязкой к конкретным ограничениям и последствиям;
- оформляет новые задачи, уточняет недостающие детали перед тем, как они уйдут в разработку;
- синхронизирует изменения между командами;
- следит, чтобы изменения в одном месте не противоречили ранее принятым решениям.
Аналитик должен помогать удерживать систему в управляемом состоянии, поскольку в backend-only проектах особенно быстро накапливается скрытая сложность: добавился новый параметр в контракте, изменилась логика статусов, появился временный обходной сценарий — и если это не фиксировать в документации, через полгода никто уже не вспомнит, почему именно так устроено поведение сервиса.
Кроме того, аналитик может участвовать в мониторинге и работе с инцидентами, например:
- расшифровывать алерты и понимать, какая бизнес-логика стоит за технической ошибкой;
- анализировать обращения с линии поддержки, отделяя реальный дефект от особенностей поведения системы;
- выявлять повторяющиеся проблемы и превращать их в задачи на доработку или изменение требований;
- уточнять SLA и бизнес-критичность инцидентов.
Аналитик — не технический писатель, а помощник
Отдельный момент, о котором я бы хотела порассуждать: очень часто разработчик принимает отдельные технические решения по ходу реализации, поскольку он глубже погружен в детали, лучше понимает ограничения фреймворка или базы данных и может предложить более рациональный способ реализации, чем изначально предполагалось в документации. Я считаю, что это нормально, поскольку в backend-only проектах техническая экспертиза разработчика действительно определяющая. Именно поэтому иногда задача аналитика состоит в том, чтобы зафиксировать принятое решение: обновить документацию, скорректировать описание логики, привести в соответствие контракт или диаграмму.
При этом нельзя сказать, что аналитик таким образом превращается в технического писателя, в этом случае его роль — удерживать целостность картины, чтобы бизнес-логика, контракты, ограничения и принятые архитектурные договоренности были зафиксированы и понятны всем участникам проекта.
В backend-only проектах это особенно важно, потому что нет интерфейса, который наглядно может продемонстрировать, как всё работает: система живет в данных, API и интеграциях, и поэтому без структурированной документации быстро теряется понимание того, как система устроена.
