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

Условный кейс — система приёма документов. В проектном решении по интеграции предусмотрена асинхронная обработка: потребитель вызывает POST /documents, получает operationId, затем запрашивает результат через GET /operations/{id}. Эта же последовательность показана на диаграмме взаимодействия.

А в OpenAPI для POST /documents указан ответ 201 Created с documentId. Метода получения статуса операции в контракте нет.

Это уже архитектурный вопрос: по какой модели должна работать интеграция? Потребителю нужно ждать создания документа или отслеживать отдельную операцию?

Для первого прохода даю ИИ три материала: проектное решение, диаграмму взаимодействия и OpenAPI. Запрос простой:

«Проверь согласованность сценария загрузки документа в этих трёх материалах. Сопоставь последовательность вызовов, модель обработки, идентификаторы, ответы и обработку ошибок. Для каждого расхождения укажи конкретные места в документах. Если данных недостаточно — так и напиши. Не предлагай менять архитектуру».

Ожидаемый результат — не замечания к коду, а перечень противоречий с указанием источников. Например: «Проектное решение требует operationId и отдельный запрос статуса; в OpenAPI описан documentId и запрос статуса отсутствует».

Дальше архитектор выясняет, какой вариант согласован, и какие материалы нужно исправить. Такое ревью можно провести до начала интеграционной разработки.

Источники: OpenAPI Specification: https://spec.openapis.org/oas/v3.1.1.html arc42 — описание сценариев взаимодействия: https://docs.arc42.org/section-6/

#Архитектура #КорпоративнаяАрхитектура #ИИ #Автоматизация #API