Комментарии 15
чё то не совсем понял с этими картинками, почему они все 3 одинаковые?
Красное - значит упал модуль. Падает один - за ним падает второй. И так далее по цепочке
не совсем понял: "Например, у нас падает приложение currencies, от него падает приложение api-gateway, и по цепочке от него может упасть приложение sbp. То есть, казалось бы, sbp не использует никакой функциональности currencies, но онo (приложение) транзитивно падает от того, что падает не связанное с ним приложение. " разве такая проблема не может возникнуть при отсутствии циклических зависимостей, типо того:
Может. Но тут благодаря циклической зависимости sbp начинает зависеть от тех модулей от которых не должен
При графе к котором нет циклов у тебя только одна направленнойсть графа. И твое приложение может упасть по понятным причинам
При появлении ациклической (или нескольких ациклических зависимостей) твой модуль начинает самопроизвольно зависеть от непонятного количества модулей (казалось бы не имеющих отношения вообще к твоему продукту)
В правой части разве стрелки не должны смотреть от module-1, или я не так понял?
Нельзя делать зависимость от card-info до module-1 так как module-1 абсолютно не стабильный, card-info абсолютно стабильный
Речь идёт о какой-то приблуде (так понимаю полностью самописной), которая считает метрики про которые Боб Мартин писал книжке "чистая архитектура"? Упомянутая Zipkin Dependency тоже так может?
Zipkin Dependency - либа которая поможет понять какие сервисы с какими связаны (зависят) в системе на основе трассировки вызовов. Посчитать на сколько правильно они связаны можно как раз по формулам дядюшки Боба. Я сделал для этого инструмент внутри компании
Классная статья, выглядит так, будто это реально приносит пользу в процессах. Возможно я упустил, за-open-source-ен ли сам инструмент или там всё скажем так тривиально и нет смысла open-source-ить его?
Все приложение состоит в основном из инфраструктурных вещей. Например, написать запросы в graphql для получения информации по модулю и записи предупреждений, скачивание модуля из внутреннего репозитория, что характерно только для внутренней инфраструктуры. К тому же в наших приложениях используется общая библиотека - платформа - поэтому не так просто что-то выложить без нее.
А подсчет нарушения принципов на самом деле тривиален:
Для первого принципа - это просто рекурсивный обход графа
Для второго принципа - подсчет по формуле соседних зависимых модулей
Для третьего принципа немного сложнее - надо выкачать репозиторий (так как у нас в продукте используется java/kotlin) то помогает библиотека JGit, а для построение AST дерева используется библиотека kotlin-compiler-embeddable от Jetbrains
Спасибо за пересказ уже написанного в книге чистая архитектура
Всегда пожалуйста! Но если это был сарказм, то тут про практическое применение этих принципов, если рассматривать микросервис как модуль. На хабре есть подробные статьи - но они исследуют на основе этих принципов зависимость модулей на основе исходного когда / исходного кода от библиотек (например через pom файл)
Наедине с микросервисом — как забороть тревожность