Все приложение состоит в основном из инфраструктурных вещей. Например, написать запросы в graphql для получения информации по модулю и записи предупреждений, скачивание модуля из внутреннего репозитория, что характерно только для внутренней инфраструктуры. К тому же в наших приложениях используется общая библиотека - платформа - поэтому не так просто что-то выложить без нее.
А подсчет нарушения принципов на самом деле тривиален:
Для первого принципа - это просто рекурсивный обход графа
Для второго принципа - подсчет по формуле соседних зависимых модулей
Для третьего принципа немного сложнее - надо выкачать репозиторий (так как у нас в продукте используется java/kotlin) то помогает библиотека JGit, а для построение AST дерева используется библиотека kotlin-compiler-embeddable от Jetbrains
Всегда пожалуйста! Но если это был сарказм, то тут про практическое применение этих принципов, если рассматривать микросервис как модуль. На хабре есть подробные статьи - но они исследуют на основе этих принципов зависимость модулей на основе исходного когда / исходного кода от библиотек (например через pom файл)
Zipkin Dependency - либа которая поможет понять какие сервисы с какими связаны (зависят) в системе на основе трассировки вызовов. Посчитать на сколько правильно они связаны можно как раз по формулам дядюшки Боба. Я сделал для этого инструмент внутри компании
Может. Но тут благодаря циклической зависимости sbp начинает зависеть от тех модулей от которых не должен
При графе к котором нет циклов у тебя только одна направленнойсть графа. И твое приложение может упасть по понятным причинам
При появлении ациклической (или нескольких ациклических зависимостей) твой модуль начинает самопроизвольно зависеть от непонятного количества модулей (казалось бы не имеющих отношения вообще к твоему продукту)
Есть интервью с создателем этого канала. Он говорит - что не собирает никаких данных, а компанует их из слитых источников. То есть эти данные уже утекли - и он их только аггрегирует и отдает в удобном виде, тем самым помогая людям понять, что со своими данными надо обращаться аккуратнее (ведь каким-то образом они уже утекли в сеть).
Странная, конечно, у злодеев логика, но они думают сами, что ничего плохого не совершают
Как же это смешно — наблюдать со стороны. Как государственные мужи требуют продлить то, чего они не понимают. Они даже спросить не удосужились. Первый же вопрос человеку, связанному с IT — и будет ответ, что это невозможно. Напоминает ситуацию с оконечным шифрованием на устройствах, ключ к которому надо выдать для расшифровки переписки на сервере
Я ожидал от этой статьи скорее «почему это плохо». Например, что ошибка в одном из очень используемых пакетов приведет к падению огромного количества проектов при обновлении. Или, например, долгую компиляцию на серверной стороне (или долгое выкачивание зависимостей, что сильно осложняет CI/CD). Или необходимость выкачивать в браузере большое количество не полностью используемых скриптов… И все это со ссылками конкретно на ваш случай…
Все приложение состоит в основном из инфраструктурных вещей. Например, написать запросы в graphql для получения информации по модулю и записи предупреждений, скачивание модуля из внутреннего репозитория, что характерно только для внутренней инфраструктуры. К тому же в наших приложениях используется общая библиотека - платформа - поэтому не так просто что-то выложить без нее.
А подсчет нарушения принципов на самом деле тривиален:
Для первого принципа - это просто рекурсивный обход графа
Для второго принципа - подсчет по формуле соседних зависимых модулей
Для третьего принципа немного сложнее - надо выкачать репозиторий (так как у нас в продукте используется java/kotlin) то помогает библиотека JGit, а для построение AST дерева используется библиотека kotlin-compiler-embeddable от Jetbrains
Всегда пожалуйста! Но если это был сарказм, то тут про практическое применение этих принципов, если рассматривать микросервис как модуль. На хабре есть подробные статьи - но они исследуют на основе этих принципов зависимость модулей на основе исходного когда / исходного кода от библиотек (например через pom файл)
Вы правы, спасибо что заметили. Заменил картинку - у модуля module-1 должны быть только исходящие зависимости
Zipkin Dependency - либа которая поможет понять какие сервисы с какими связаны (зависят) в системе на основе трассировки вызовов. Посчитать на сколько правильно они связаны можно как раз по формулам дядюшки Боба. Я сделал для этого инструмент внутри компании
Нельзя делать зависимость от card-info до module-1 так как module-1 абсолютно не стабильный, card-info абсолютно стабильный
Может. Но тут благодаря циклической зависимости sbp начинает зависеть от тех модулей от которых не должен
При графе к котором нет циклов у тебя только одна направленнойсть графа. И твое приложение может упасть по понятным причинам
При появлении ациклической (или нескольких ациклических зависимостей) твой модуль начинает самопроизвольно зависеть от непонятного количества модулей (казалось бы не имеющих отношения вообще к твоему продукту)
Красное - значит упал модуль. Падает один - за ним падает второй. И так далее по цепочке
Для меня лично тут 2 препядствия
Крупнейшие it работодатели это банки. Банки не it компании так как зарабатывают на комиссиях и обслуживании
Я не могу взять it ипотеку если до этого когда-то пользовался какой то гос программой ипотечного кредитования
Есть интервью с создателем этого канала. Он говорит - что не собирает никаких данных, а компанует их из слитых источников. То есть эти данные уже утекли - и он их только аггрегирует и отдает в удобном виде, тем самым помогая людям понять, что со своими данными надо обращаться аккуратнее (ведь каким-то образом они уже утекли в сеть).
Странная, конечно, у злодеев логика, но они думают сами, что ничего плохого не совершают