Много встречал разговоров про то, что архитектурные описания - это модели, но ни разу не видел вблизи процесса, реализующего работу с архитектурными описаниями, как с моделью системы. Ведь как было бы хорошо - есть система, рядом есть её модель в виде архитектурных описаний и они как-то более менее синхронно развиваются - и вот у нас есть живая работающая система, а к ней прилагается актуальное описание архитектуры.

На практике же все совсем не так. На начальном этапе продукта/проекте еще кто-то думает про архитектуру, рисует красивые схемки, модели и прочие описания, потом по ним что-то реализуется... А дальше система сама по себе, а архитектура - сама по себе. В лучшем случае есть реестр ADR-ок, как набор событий в Event Sourcing. И если тебе надо понять, что же там в системе на самом деле - то надо либо прочитать и осмыслить весь журнал ADR-ок, либо идти реверсить код. И второй вариант кажется более практичным...

Пытаюсь выстроить работу с архитектурой, как с моделью, на практике.
Пришел к тому, что нужно развивать поддерживать следующие модели:
1. Модель текущего состояния системы. Отражает факт. Применяется для анализа возможных изменений, онбординга, источник картинок для документации по системе. Акцентируется на фактическом состоянии архитектурных элементов и их взаимосвязей.
2. Модель возможного будущего. Отражает мечты и возможные планы. Используется для для планирования будущих работ и презентаций руководству. Зыбкая, часто изменяемая. Акцентируется на крупных элементах и отношениях, без внимания к деталям.
3. Модель планируемых изменений. Отражает изменения текущего состояния в рамках постепенного движения к светлому будущему. Акцентируется на том, какие архитектурные элементы нужно добавить/изменить/удалить в рамках развития системы. Из таких моделей формируется ADR.

Осталось только придумать, как всё это реализовать на Archi.
#моделирование #archi