Comments 8
Я с большим уважением отношусь к вкладу в подход "Архитектура как код". Считаю, что пора выводить его из "pet" во взрослые промышленные решения. Растить его зрелость.
Для этого нам нужна открытая экспертная дискуссия. Именно это меня мотивирует написать рецензию на данную статью, а в оригинале на видео конференции ArchDays.
Анализ:
Внимательно изучил видео и репозиторий проекта. Предложенная идея и ее реализация стоит внимания потому, что старается решить актуальную задача - устранить разрыв между проектной документацией и реализацией. Это одна из ключевых проблем лежащих в основе самой ценности проектирования. Также, важным является наличие потенциала к автоматизации.
Однако, в идее есть врожденные ограничения из-за попытки все "упростить". На мой взгляд, именно они будут сковывать применение.
Видео метка (0:00): Отличное, мягкое погружение в тему и проблематику. Откровенно завидую подаче материала и способности объяснять все просто.
Видео метка (4:10) Рассматриваются два языка описания диаграмм кодом PlantUML и Structurizr. Утверждается, что они одинаковы по мощностям. Это неверно. PlantUML имеет гораздо более широкие возможности по устоявшимся нотациям. Например, позволяет описать диаграммы взаимодействия, сетевые зоны, алгоритмы и т.п. Structurizr вводит свою нотацию - C4 Model. Это, по сути, все, что он готов нам предложить.
Видео метка (4:31) Предлагается "выкинуть" все из PlantUML и оставить только нотацию С4 Model катастрофически сократив возможности PlantUML. Встает вопрос - почему не взять сразу Structurizr? Скорее всего, потому, что он не дает всех тех возможностей, что есть у PlantUML по созданию своего DSL.
Видео метка (5:11) Утверждается, что все очень просто, т.к. больше ничего и не нужно кроме C4 Model. Это утверждение неверное. C4 Model недостаточна для полноценного описания архитектуры решения. Например, важны не только связи, но и их последовательность.
Видео метка (5:52) Подводится промежуточный итог. Мне кажется важным в него добавить: Взят PlantUML и обрезан до C4 Model волевым решением автора потому, что "больше ничего не нужно". Это фундаментальное решение из которого затем строятся все выводы доклада и ценность идеи.
Видео метка (6:45) Заявляются проблемы:
1. Актуальность архитектурного описания;
2. Достаточность архитектурного описания (декларативность). Здесь хочется отметить, что до этого были "отрезаны" от PlantUML имеющиеся возможности для этого;
3. Отсутствие контроля.
Видео метка (9:00) Звучат слова, которые подменивают суть произошедшего до этого. Говорится, что у нас теперь архитектура as code. Это неверно. У нас все еще диаграммы как код. Они, т.е. диаграммы, описывают архитектурное решение для восприятия человеком. Их код лишь помогает работать с диаграммами как кодом. Т.е. это Doc as Code и DocOps. Именно по этой причине, одна диаграмма не описывает полноту архитектурного решения. Человек не способен прочесть такую диаграмму.
Видео метка (10:27) Стоп... а почему мы оперируем всего тремя сущностями из C4 Model? Где сущность software system (не внешней, а нашей системы)? Выглядит так, что мы не просто взяли C4 Model, но и отрезали от него все кроме описания контейнеров.
Видео метка (12:44) Вводится идея "поженить" IaaC с AaaC. Т.е. рассматриваются широкие понятия, которые включают в себя, например Terraform как индустриальный стандарт для облаков. Но вводится очередное ограничение - k8s. Это аргументированно объясняется. У кубера конфиги. Их мы можем однозначно интерпретировать. Но, например, с Terraformom такой "фокус" не пройдет. Т.к. он может включать в себя алгоритмические конструкции и условия.
На этом этапе у меня создалось впечатление, что широкий заход на IaaC и AaaC, фактически, реализуется тотально урезанной нотацией PlantUML для использования в паре к k8s. Т.е. решение имеет крайне узкую нишу применения.
Видео метка (15:00) Объясняется как можно сверить архитектурное решение заложенное в диаграммы и конфигурацию кубера. Для этого, очевидно, нужно распарсить все диаграммы и все конфиги. Выглядит несложно технически. На деле, это значит, что нужно организовать управление диаграммами в определенной нотации. Ввести внутренние соглашения о их размещении и актуализации...
Стоп... актуализации? Т.е. та самая проблема, которая должна была решиться, возникает в новом качестве? Теперь она блокирует развертывание не только, если у вас что-то в коде и конфиге не так. Теперь придется найти ту самую диаграмму которая не сходится с конфигом и ее тоже поправить. Как ее найти? Кто поправить должен? Решение не предложено.
Видео метка (19:00) Очевидно, что базового языка PlantUML недостаточно для задач, которые сформулированы. Нужны дополнительные метаданные. Для этого предлагается ввести теги. PlantUML тут хорошо помогает. Но проблема в том, что эти теги должны как-то декларироваться. Кем? Как? Если этого решения нет, то вероятность ошибок в коде диаграмм будет велико, что может создавать серьезные проблемы для развертывания. Ведь без тестов мы не катим теперь?
Далее вводится еще масса кастомных форматов и семантики. Становится ясно, что для комфортного использования данного решения потребуется инструментарий в IDE.
Выводы:
1. Решение имеет определенный потенциал к развитию. Для этого его требуется обогатить инструментарием, который позволит участникам производственного процесса удобно писать необходимый код, а также локализовывать источники проблем для быстрого устранения.
2. Решение имеет узкий ландшафт практического применения. На мой взгляд эта проблема в текущей концепции неразрешима. Требуется отказаться от идеи, что код диаграмм это код архитектуры. Код архитектуры должен полностью описывать архитектурное решение, позволяя генерировать необходимые артефакты. В том числе и диаграммы.
3. Несомненно, пройденный путь и идеи делают ценный значительный вклад в развитие и популяризацию подхода AaaC.
P.S. Большое спасибо за Вашу работу!
На мой взгляд критика с одной стороны справедливая, потому что "по сути" все так и есть и все перечисленные недостатки присутсвуют.
Но с другой стороны, не совсем корректная, т.к. очевидно, что человек применил свой подход именно в той предметной области и к тем проектам с которыми он работает, и ввел ограничения удобные именно для его ситуации. Сразу строить систему которая бы охватывала все возможные случаи и подходила бы всем и каждуому было-бы невозможно чисто по временным и техническим (надо на чем-то это все тоже тестировать!) причинам.
Тут скорее тем кому не подходит это решение в лоб нужно творчески подойти к вопросу и если можно так выразиться провести "рефакторинг", чтобы расширить возможности применения этой идеи.
Спасибо за подробный разбор :) Отчасти согласен, но далеко не со всем. К примеру:
Стоп... актуализации? Т.е. та самая проблема, которая должна была решиться, возникает в новом качестве? Теперь она блокирует развертывание не только, если у вас что-то в коде и конфиге не так. Теперь придется найти ту самую диаграмму которая не сходится с конфигом и ее тоже поправить. Как ее найти? Кто поправить должен? Решение не предложено.
Как раз на самом раннем этапе тест и покажет максимально точно что и где нужно поправить. Если нужны изменения в архитектурной схеме — это делает разработчик и отправляет на ревью архитектору (ответственному за архитектуру решения тимлиду/техлиду).
В целом, как в треде уже отметили — это лишь первый шаг, на котором я не остановился (к примеру есть уже следующий шаг в плане автогенерации архитектурных схем) и не планирую останавливаться в дальнейшем =)
Шикарная идея, аж захотелось попробовать на следующем проекте
Очень интересно! Не подскажите, пожалуйста, книжек на тему архитектуры? Хотелось бы почитать про ACL и подобные паттерны
Лично мне нравится ресурс: https://microservices.io/
Конкретно про ACL-паттерн, есть здесь: https://learn.microsoft.com/en-us/azure/architecture/patterns/anti-corruption-layer, но в несколько другом варианте реализации.
Также у меня есть несколько докладов про архитектуру и паттерны. Тут в том числе про ACL паттерн:
А тут в целом про более общие принципы проектирования:
Покрытие архитектуры as Code тестами