Изменения

Критическая часть. Что такое архитектура? Говорят, что это набор взаимосвязанных технологических и технических решений. В этом опредлении определении нет архитектора. И в DevOps разработки процессе архитектора тоже нет, функция архитектуры не выделена. Получается, что архитектура - это умозрительный феномен, который мы моем исследовать для влияния на него. В такой постановке роль архитектора софта сравнима с ролью архитектора городской застройки в условиях, когда люди массово строят самостоятельно и потому застройка получается сильно разнообразной с слабо соответствующей замыслам.

Между замыслом и реализацией - разрыв. Архитекторы разъясняют замысел. А можно - просто сделать. Архитектурная функция в виде созадения создания диаграмм - не эффективна.

Что предлагается как решения? Архитектор 2.0 описывает арзхитектуру архитектуру как код, на некотором языке. Описание в виде кода уже зарекомендовало себя для инфраструктуры, и предлагается использовать этот опыт.* Единое пространство для описания, в котормо работают архитекторы и разрабочикиразработчики

* Описание и использование архитектурных паттернов подобно использвоанию бибилиотек использованию библиотек при разработке

Осталось изобести код изобрести язык архитектуры. * Это не PlantUML и Structurizr - они презназанчены предназанчены для поисания описания диаграмм, а не для описания архитектуры как таковой. По необходимости их можно порождать.* Описание должно читаться человеком и машиной, и порождаться челвоеком человеком и машиной.* Основой архитектуры сейчас являютя являются контракты между доменами. Их описаняе описание понятно разработчикам, был пример.

* Все описаняи описания собираются в Архитектурный DataLake, и мы можем проводить анализ, соотносить структуры в разных доменах, выделять шаблоны.

Есть пример реализации такого подхода, сделанный самим Романом - DocHub. Он не наставиваетнастаивает, могут быть альтернативные реализации. А можно подключитсья подключиться к сообществу DocHub и начать его развивать - это open source проект. При этом низкий порог входя - есть plugin к IDEA, так что можно сразу использовать.

Теперь поделюсь, что я обо всем этом думаю. Говоря об архитектуре, очень аважно важно различать саму архитектуру и архитектурные описания. Диаграммы - лишь описание. И обычнфый обычный подход состоит в том, что архитектура - она в головах, а диаграммы помогают ее передавать между головами. Роман выносит архитектуру из голов в описание, и это - принципиальный, очень важный переход. Это - изменение мышления. И эта идея - очень правильная.

Однако, в практическом применении подхода есть ряд проблем, с которыми неясно, что делать. И тут нужны практики. которые позволят с этим жить внутри разработанных инстурментовинструментов. Какие я вижу проблемы?* Каждая архитектура проходит этап эскизирования, когда формальное описание еще невозможно. И при проектирвоании проектировании у нас неравномерная картина: что-то уже определено достаточно конкретно, а что-то - еще в зоне неопределенности, и надо уметь делать такое смешанное описание.* Взаимодействие между компонентами - это уровень архитектуры приложений. А есть еще бизнес-уровень, при этом для него тоже интересно описание архитектуры в виде кода, таким образом. чтобы можно было трассирвоать трассировать исполнение бизнес-процессов по цифровому следу в логах различных систем, соотносить идеальную картину с реальной. То, для чего замысливался Archimate - описание связи бизнес-приложения-компьютеры. Я вижу тут большой потенциал. И тут особенно важно как раз смешанное описание различной жесткости, потому что новый процесс не только преоктируется проектируется в эскизах. он и отрабатывается со слабой формализацией, с опорой на разумное поведение людей, и при этом на этапе отработки тоже интересно наблюдать, как все реализуется - эскизные с некоторого уровня должны стать машиночитаемыми.* Описывается конструкция, за рамками остабются остаются основания для приняытых принятых решений. Почему систему разделили именно на такие компоненты? Почему были выбраны именно такие протоколы? И так далее. Понятно, что это, вероятно, текстовые описания, но важно, чтобы они были где-то в едином репозитарии, были предусмотрены места. Это как с описаниями классов и функций, обираемому по специальным комментариям в коде - эти комментарии должны быть структурными.

А еще у меня есть определенный скепсис, связанный с тем, что инструмент для описания архитектуры уже создавали - Enterprise Architect. Там тоже расширяемая метамодель, и много других возможностей. То есть подход, для которого создавали инструмент - тот же самый. Успеха не получилось, инструмент - сложен, и есть кейсы, когда он испольуется используется аналитиками внутри, а для разработчиков порождаются документы, потмоу потому что разбираться в моделях разработчики не хотят. Есть кейсы, когда возможность создания единой модели - игнорируется, вместо нее используется много фрагментарных. И так далее. И с этим связаны сомнения. Но понятно, что довольно много недостатков EA в DocHub преодолено за счет версионирования моделей, текстовых описаний, открытого кода и доступного развития сообществом. Этого может оказаться достаточно. Но, может быть, проблемы не только в инструментах, но и в подходе.

А если говорить об альтернативных инструментах, то полгода назад на конференции TrueTech я слушал рассказ X5 про создание своего инструмента для ведения архтектуры архитектуры предприятия. Перед решением о разработке они смотрели DocHub, правда это было полтора-два года назад. Но им было важна связь с бизнес-процессами, а этого действительно нет. Но в отличие от DocHub их инструмент пока недоступен - они говорили, что готовы к пилотам с заинтересованными компаниями с тем, чтобы убрать специфику, и только потом будут делать доступное решение. Подробности можно посмотреть в [[Блог:Максима Цепкова/2023-05-04: TrueTechDay - живая конференция и хороший контент|моем отчете]].

Основной тезис доклада: хаос на проекте в условиях приближающихся сроков - хорошее время для интенсивного, взрывного роста на испытальном испытательном сроке. Иллюстрирован собственным кейсом. Ему неудобно говорить от первого лица, поэтмоу поэтому аватар-растение Митроша. Он что-то умеет в аналитике, запустил несколько проектов, окунулся в банки, работал с БД, хочет освоить фронт и бэк. Проект Единый фронтальное решение ЕФР - интеграция всей работы операциониста, стартовал с зимы, он пришел летом, команда собралась, но уже приближается первая контрольная точка, а работа не продвигается. При этом команда новая, большая неизвестность по legacy и менеджменту.

* Архитектуры. Самое главное в этом - как команда разработки разбита по отдельным командам - закон Конвея. Архитектурные стили. Способ развертывания - аналитик об этом вообще не думываемдумает, а он влияет на способ независимой доставки частей. Нефункциональные требования критично влияют на архитектуру, и вот этой части аналитик обычно не умеет совсем. Характеристики системы, которым должна отвечать система. А регулярно их просто вставляют в ТЗ, особо не вникая, потмоу потому что не понимают. Литература: Ричардс и Форд Фундаментальный подход к архитектуре и Современный подход к архитектуре, еще несколько книг. Роль аналитика тут - организатор и фасилитатор работы, чтобы бизнес-заказчики и разработчики искали реальное решение там, где оно нужно.

Компоненты - надо знать слои: чистая архитектура, луковая архитектура, best practice для каждого уровня - rich, anemic, event, ORM, аспекты и т.п. Модкульный Модульный монолит или микросервисы, способы блокировки и так далее. Фаулер Шаблоны корпоративных приложений. И еще много - DDD, Чистая архитектура, книжки от MS. Но там есть хорошие и вредные советы, надо различать.

Контейнеры - соответствие системы целевому назначению - реализация фич и атрибутов качества. Надо знать стек технологий, распределенные оказоустойчивые отказоустойчивые системы, способы хранения данных, message broker, CQRS и так далее. Доклад Помодорова, там детали