Архитектура системы начинается не с прямоугольников и стрелок на диаграмме. Она начинается с требований.

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

Аналитику потребуется определить: — какая система является источником данных; — кто инициирует обмен; — каким способом системы взаимодействуют; — какие данные передаются; — в каком формате; — требуется ли авторизация; — что считать успешным результатом; — что делать при ошибке; — требуется ли повторная отправка; — где хранить полученные данные. После ответов начинает появляться архитектура.

Например: Внешняя система ↓ REST API Интеграционный сервис ↓ Сервис обработки данных ↓ База данных ↓ Сервис формирования документа

Но даже такая схема ещё недостаточна. Для каждой стрелки желательно понимать как минимум три вещи: — Кто инициирует взаимодействие. — Какие данные передаются. — Как получатель сообщает результат. Тогда архитектурная диаграмма перестаёт быть иллюстрацией и становится рабочим инструментом анализа. Поэтому при проектировании полезно двигаться не от блоков к требованиям, а наоборот:

требование → сценарий → данные → взаимодействие → компоненты → архитектурная схема.

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