Comments 3
Подходы architecture as code и infrastructure as code - явления не новые и широко применяются.
А потом начинается архитектура.
Через месяц сервис переименовали, интеграцию переделали, команда-владелец сменилась, а прямоугольник продолжает жить своей жизнью.
Проблема в этих цитатах. Потому что архитектура должна появиться ДО, а не потом. И интеграцию должны были переделывать, потому что она стала в архитектуре описываться по-другому.
А если воспринимать архитектуру как документирование того, что уже есть, то да, ручное её рисование в drawio будет неизбежно отставать.
Представьте, что вы стоите дом. Наверное, вы сначала нарисуйте план, потом сделаете чертежи, потом по этим чертежам построите, а потом зафоткаете, как реально проложили электрику и трубы в стяжке и стенах, чтобы потом случайно их не продырявить. Так вот, план и чертежи, которые делаются до стройки - это архитектура. Исполнительная документация (как реально построили) - это не архитектура.
Вы описываете проблему создания исполнительной документации (которая в ИТ системах должна делаться автоматически) и называете это проблемой отставания архитектуры.
Ну и ещё. Подход Architecture as code очень даже существует, даже в России, особенный буст он получил при появлении LLM, но только не для устранения отставания архитектуры, а для ускорения PDLC.
Идея перегонять “квадратики” (т.е. графическое представление) в код и обратно на моей памяти была последний раз по-крупному похоронена вместе с Rational Rose. Одной из фундаментальных причин этого было принципиальное различие сценариев использования одного и второго. Если для кода важны такие вещи как полнота, точность, корректность, то для графического представления гораздо важнее простота создания/изменения и наглядность. Сначала вы замучаетесь рисовать все детали на диаграмме, потом упаритесь поддерживать их в актуальном состоянии. И в конце концов обнаружите, что одни предпочитают неверифицируемые спеки и махание руками на митингах, потому что ваша диаграмма “слишком техническая”, а другие читают сразу код - потому что он в конечном счете работает и является source of truth, а ваша диаграмма - лишняя абстракция над ним. Поэтому в следующий раз вы просто за 5 минут нарисуете квадраты со стрелочками, наглядно объясните всем свою идею, потом выкинете ее, заново перерисуете, опять выкинете и поедете дальше.
Это было про графику. Но у вас статья не про графику. У вас некий редактор компонентов, который позволяет описывать эти компоненты в предопределенных формочках, а потом уже представлять графически, а также в виде yaml или json. Тут можно только пожелать удачи, конечно… Еще наверное можно посоветовать посмотреть на языки конфигурации типа pkl, nickel и другие.
Почему архитектура до сих пор живёт в прошлом?