Всем привет!

Нужно ли хранить информация об архитектуре АС?
Я считаю, что да, нужно.
Почему?
1) контроль интеграций
2) контроль использования компонентов и технологий
3) обмен информацией между командами

Т.к. в канале была серия про AI - вспомним его и сейчас. А что если AI агент будет ходить по репозиториям и собирать информацию об архитектуре в одном месте? В теории да, но есть ряд важных нюансов:
1) доступы ко всем репозиториям. В целом решаемо.
2) достаточность данных в коде для точного определения архитектуры. Трудно решить, часто нужных данных просто нет в коде, т.к. они стендозависимы. Отсюда потенциальные пробелы и галлюцинации.
3) мы получаем слепок AS IS, но TO BE все равно придется рисовать ручками

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

Поэтому пока рассмотрим другие варианты.

Ок, заводим отдельную АС для хранения архитектуры. Есть UI, можно легко описывать компоненты, интеграции и технологии.

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

Что же делать? А пусть команды сами выбирают, кто отвечает за описание. Весьма вероятно, что этим кем-то станет аналитик. Аналитик конечно же знает архитектуру, но сверху, до определенного уровня. Например, на уровне единиц деплоя, технологий точно будут проблемы. Ок, архитектура описана. К чему приведет данных подход? К тому, что в нашей архитектурной АС будет некое представление актуальной архитектуры, неполное, устаревшее сразу после создания. И поддерживать такую архитектуру в актуальном состоянии никто не будет. Если только из под палки. И самое главное - системой никто не пользуется. Но заполнять надо(

Итого - так можно, но не нужно делать.
Какие главные проблемы:
1) нежелание разработчиков работать за пределами IDE. А именно разработчик понимает архитектуру в целом, как минимум с уровня Senior
2) UI представление данных, к которому так просто не применишь diff и которое легко сломать
3) разрыв AS IS и TO BE - релиза и архитектуры

И, соответственно, как их фиксить:
1) у нас есть IDEA и рабочий проект в git, архитектура должна лежать в проекте вместе кодом. Также нужен плагин IDEA для удобства работы с файлами архитектуры
2) по аналогии с Infrastructure as Code, Documentation as code - Architecture as Code. Вообще говоря Everything as Code, но сегодня про архитектуру). Т.е. все в текстовом виде. OpenAPI, PlantUML в эту парадигму отлично вписываются
3) актуальная архитектура хранится в ветке релиза и согласовывается командой на уровне Pull Request (Merge Request). Целевая - в централизованном репозитории, тоже в git. Актуальная архитектура синхронизируется с целевой тоже через Pull Request, но уже с другими согласующими.

Если до сих пор казалось, что я слишком абстрактен - открою тайну, я веду к конкретной системе, о которой недавно узнал - DocHub.
Снова спасибо @AViIgnatov

Исходники https://github.com/DocHubTeam/DocHub
Живой проект с описанием архитектуре на примере самого себя: https://dochub.info
Цикл статей на Хабре: https://habr.com/ru/articles/659595/ и далее по автору.
К слову, разработка российская, из rabota.ru

Итого: я не уверен, что DocHub - это серебряная пуля. Не могу гарантировать, что он решит проблему контроля и вообще наличия актуальной архитектуры в компании. Все-таки, повторюсь - очень мало людей хотят описывать архитектуру, во многих командах нет соответствующей роли. Я про факт, а не формальности. Но у данного подхода IMHO шансов побольше, чем у всего, что я видел.

#aac #arch

Всем привет!

Хочу порекомендовать хорошую статью на Хабре о необходимости кэша.
https://habr.com/ru/companies/oleg-bunin/articles/883422/
Со сравнительными тестами Redis, Memcached, PostgreSQL и MySQL.

Из статьи я почерпнул для себя несколько основных тезисов:

1) в наше время получить 1 000 000 rps с сервера на чтение - это реальность. И это круто! Речь про стандартный сервер, а не 100 ядер\1000 Гб памяти как можно было бы подумать

2) реляционные СУБД приблизились к кэшам (key-value noSQL хранилищам если хотите) по скорости чтения

3) как правильно заметил автор: будь он СТО - не разрешил бы использовать СУБД как кэш. И вот почему. Сравнимая производительность БД-кэш достигается при 2 условиях - нет операций записи в БД (а соответственно и блокировок записей) и все выборки идут по первичному ключу (это самая быстрая операция выборки). Казалось бы - соблюдай эти условия и все будет работать. Но ведь у нас СУБД. Окей, GRANT на запись отберем у всех. Но ведь СУБД может сложные JOIN-ы. И это никак не ограничить правами. Там могут быть сложные индексы. И рано или поздно найдется разработчик, которые эти возможности захочет использовать))) И в пике производительность упадет даже не в разы, а на порядки. Например, не провели НТ. Или забыли обновить профиль НТ. С кэшом такого по понятным причинам не произойдет. Вывод - у каждого инструмента свое назначение.

4) проблема неконсистентности данных кэш-БД все равно будет. Поэтому перед тем, как добавлять в систему кэш - стоит подумать, провести НТ и еще раз подумать. Возможно где-то есть или планируется архивная реплика БД. Там проблема констистентности данных решается механизмом репликации .Если часть нагрузки на чтение увести на нее - возможно кэш и не нужен.

P.S. Отдельная интересная тема: PostgreSQL показывает, что принцип число процессов ОС = числу ядер - не аксиома)

#rdbmc #cache #arch_compromises

Всем привет!

Я уже писал про то, что не люблю код, в котором интерфейсы делаются ради интерфейсов. Самый яркий антипаттерн: интерфейс с единственной реализацией, лежащей рядом. Подозреваю, одной из причин такого проектирования является принцип Dependency Inversion - в модели должны быть интерфейсы, а в сервисном слое - их реализации. И они разнесены по разным слоям приложения. Тут вроде все сходится?
Как бы да, но я нашел интересное возражение: https://habr.com/ru/articles/888428/
Как всегда побуду в роли ChatGPT) Суть статьи, а точнее продвигаемого там принципа структурного дизайна в том, что вместо создания интерфейса, любой сложный сервис можно отрефакторить (или спроектировать), выделив 3 метода:

1) чтение - все интеграции по чтению из внешних источников
2) бизнес-логика - тут должны быть чистые классы модели, принимающие на вход только простые типы или коллекции, без побочных эффектов
3) запись результата во внешние источники

2-я часть - это ядро, все остальное - imperative shell. Методы ядра вызываются из imperative shell, зависимости направлены в одну сторону.

Потенциальная проблема - возможно, читать придется много, чтобы загрузить данные для всех условий в бизнес-логике. Решение - дробить бизнес-логику на более мелкие части.
Еще проблема - как отследить, что в метод с бизнес-логикой не передали "побочный эффект". Например, класс, делающий вызов к БД - JPA lazy initialized DTO. Или ссылку на синглтон - Spring bean. Навскидку - только ручное код-ревью. Формально описать проверку объекта на отсутствие побочных эффектов сложно.
Огромный плюс - бизнес-логика всегда легко тестируется, даже без mock-ов.
Еще плюс - код проще.

Вот пример такого рефакторинга: https://www.youtube.com/watch?v=wq9LBouRULs

До чтения статьи, по заголовку, "покушение" на основы чистой архитектуры я воспринял критически. Но после ее прочтения и дальнейших размышлений идея понравилась.

Очевидно, она применима не всегда. Можно описать такую эвристику:

Простой сервис:
1) используем структурный дизайн, четко разделяем чтение с записью от бизнес-логики. С интерфейсами не заморачиваемся.
2) нужна вторая реализация какого-то сервиса - для тестового mock-а, динамической замены в runtime - легко вводим интерфейс с помощью IDE там, где он нужен

Сложный сервис, например:
1) библиотека
2) система с плагинами
3) коробочный продукт с несколькими реализациями под разных клиентов
4) наличие ядра, которое нужно защитить от правок "не доверенными лицами" -
изначально проектируем с интерфейсами в модели и реализациями в сервисах и портах\адаптерах

Принципу KISS - соответствует. Dependency Inversion - как ни странно тоже, т.к. в точной формулировке он звучит так: ядро не должно зависеть от деталей реализации. А структурном дизайне в ядро передаются только простые типы данных и коллекции с ними.

#arch #clean_code #principles

Всем привет!

Я уже подымал тему готовых архитектурных решений, а точнее их отсутствия в большинстве случаев https://t.me/javaKotlinDevOps/134
Хочу развернуть тему с другой стороны.

Стоит ли тратить силы на поиск целевого архитектурного решения?

Написал эту фразу, и понял, что не всем она может быть понятна) Расшифрую. В больших компаниях ака "кровавый enterprise" есть некий список разрешенных технологий и архитектурных принципов. Оформленный в виде техрадара, карты технологических стеков и сборника архитектурных стандартов. Это и есть целевая архитектура.

Так вот, беда с этим стандартами одна - со временем их становится слишком много, понять - как сделать правильно, чтобы работало годами без переделки - сложно. Нужно на это тратить время: для того, чтобы обойти всех заинтересованных архитекторов, смежные команды, и выработать целевое решение.

Так вот - а надо ли его искать? Несмотря на то, что ответ вроде бы очевиден, хотел бы подсветить несколько потенциальных проблем.

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

К чему это приводит? Мы потратили время на выбор и реализацию "целевки", а через год нам говорят - переделывайте. Отрицание, гнев, фрустрация. Обида на архитекторов. Причем даже если архитектор признает ошибку (и вообще эта ошибка была) - вряд ли он поможет переписать код. Обида на менеджеров - да они издеваются что ли, вечно меняют правила игры, вечная миграция... Желание сменить компанию...

Поэтому видится, что есть более надежный подход.

1) смириться с тем, что все течет, все меняется, и миграции будут всегда

2) искать целевые решение, но всегда держать в уме, что это целевое решение на данный момент

3) разделить весь код на ядро и инфраструктурный код. Ядро стараться писать на чистой Java \ Kotlin, с минимальным использованием фреймворков. Особенно, внутренних, которые еще не доказали свою стабильность. Внешние интеграции закрывать - предохранительный слой (anticorruption layer), шлюзы (gateway), адаптеры.

4) очень важно - уметь и хотеть быстро выпускать релизы, разбивать любые доработки на небольшие инкременты. Это можно сделать как улучшением качества проектирования, увеличением покрытия тестами и автотестами, так и различного рода договоренностями со смежниками, (не забываем, что мы в "кровавом enterprise")

Если вам показывался знакомым последний пункт - то да, это Agile. Или то самое снижение Lead Time (LT), о котором любят говорить менеджеры. И не только говорить) Но в данном случае они правы.

Еще пример - фондовый рынок и диверсификация. Диверсификация считается основным принципом разумного инвестора, и означает, что нельзя "класть все яйца в одну корзину". Т.е. нужно покупать разные классы активов: акции, облигации, вклады, кэш, золото, недвижимость. Причина - сложно угадать, что именно "выстрелит". В случае кода сложно конечно реализовать диверсификацию прямолинейно: часть данных хранить в PostgreSQL, а часть - в Oracle. Да и не нужно. Но предусмотреть возможность замены поставщика - нужно.

#agile #arch #arch_compromisses

Качественное ли у вас API? А чем докажете?)

Как мы проверяем код на качество? SonarQube, покрытие кода тестами. Если говорить о code style - CheckStyle-ом. Если говорить об уязвимостях - проверка по базам уязвимостей (разные тулы), Checkmarx.

А можно ли как-то проверить API на соответствие лучшим практикам? В частности, OpenAPI как самый типовой на данный момент вариант.
Да - для этого есть Spectral linter https://meta.stoplight.io/docs/spectral/a630feff97e3a-concepts

У него три основных достоинства:
1) это linter и его можно включить в CI pipeline

2) у него есть наборы предустановленных правил, в частности:
а) OpenAPI rules https://meta.stoplight.io/docs/spectral/4dec24461f3af-open-api-rules
б) URL rules https://apistylebook.stoplight.io/docs/url-guidelines - использование kebab-case, не использование get в URL...
в) OWASP rules https://apistylebook.stoplight.io/docs/owasp-top-10 - безопасность, например, использование uuid вместо чисел в идентификаторах
...

3) возможность добавлять свои правила https://meta.stoplight.io/docs/spectral/01baf06bdd05a-create-a-ruleset в том числе наследуясь от существующих

Ну и отдельно отмечу, что есть плагин для IDEA https://plugins.jetbrains.com/plugin/25989-spectral-linter

Итого - штука полезная, настоятельно рекомендую попробовать.

#api #arch #code_quality