Архитектурные представления
Тема дорожной карты · Software Architecture
Архитектурные представления (Kruchten 4+1: логическое, процессное, разработки, физическое + сценарии; или шесть представлений Rozanski/Woods) — это несколько различных взглядов на одну и ту же систему, поскольку одна диаграмма не может описать все аспекты. Разные стейкхолдеры читают разные представления: операционная команда смотрит на физическое и развертывание представления, разработчики — на логическое и представление разработки, а специалисты по безопасности — на свои специализированные представления. Важно выбрать небольшой фиксированный набор представлений и поддерживать их согласованность.
Как это работает
Выбор 3-5 представлений, действительно необходимых вашим стейкхолдерам, является ключевым шагом. Для маленькой системы типичный набор представлений может включать Context (система в среде), Logical (модули и зависимости), Deployment (топология выполнения), Data (поток и хранение данных). Каждое представление должно поддерживаться как живой документ с конкретным владельцем. При изменении системы представления должны обновляться, иначе это приведет к накоплению техничесного долга в документации.
Инструменты для создания и поддержания представлений включают PlantUML для текстовых диаграмм в git, draw.io для создания богато визуализированных диаграмм, а также Structurizr для создания C4-совместимых представлений. Эти инструменты помогают сохранять актуальность представлений и упрощают процесс их создания и обновления.
Когда применять
Добавление представлений следует проводить по мере роста системы за пределы того, где один инженер может удерживать все релевантные перспективы. Для маленькой совместно расположенной команды может быть достаточно только Context и Logical представлений. Однако для команды из 50 инженеров может потребоваться использование всех пяти Kruchten представлений плюс специализированные представления для операционной команды и безопасности.
Типичные ошибки
Одной из распространенных ошибок является view bloat — наличие 15 различных представлений, ни одно из которых не поддерживается. В таких случаях лучше выбрать меньшее количество представлений, которые действительно нужны. Другой распространенной ошибкой является наличие представлений без владельцев — когда никто не обновляет представления, они устаревают за несколько месяцев. Важно назначить конкретных владельцев для каждого представления, чтобы обеспечить его актуальность.
Также часто встречается неправильное таргетирование аудитории — когда единый "архитектурный документ" пытается обслуживать операционную команду, разработчиков и других стейкхолдеров одновременно. Это приводит к тому, что каждый читатель документа не находит нужной информации. Вместо этого следует разделить представления по аудитории, чтобы каждый стейкхолдер мог легко найти нужную информацию.