Почему появился Architect Studio
Меня зовут Дмитрий Горячев. Я проектирую информационные системы и каждый день вижу одну и ту же картину: архитектурное знание разбросано по десятку несвязанных инструментов и устаревает быстрее, чем приносит пользу. Architect Studio - мой ответ на эту проблему: я разрабатываю платформу самостоятельно и довел ее до рабочего прототипа.
Как обычно устроена работа
Знание о системе размазано по инструментам и головам:
- диаграммы - в draw.io и на досках, устаревшие через месяц;
- требования - в Confluence, без связи с реализацией;
- API-контракты - по репозиториям, версии расходятся;
- реестр сервисов - в Excel у одного человека;
- онбординг нового инженера занимает недели.
Как это устроено в Architect Studio
Единая связанная модель продукта вместо разрозненных файлов:
- домены, сервисы и БД описаны один раз и связаны между собой;
- требования (BR/FR/NFR/ADR) трассируются до задач и документов;
- диаграммы строятся из модели - и не устаревают;
- контракты OpenAPI/AsyncAPI/GraphQL/Protobuf - рядом с системами;
- экспорт в Confluence, HTML и PNG для любой аудитории.