Есть ли зависимость между метриками Solution- и Enterprise-архитектур? Принцип каскадного снижения связанности

Часто ли вы замеряете связанность и связность (или прочность) на своих проектах и системах? А на энтерпрайз-архитектуре? :)

Впервые начав измерять эти архитектурные параметры на разных архитектурных уровнях, мы приходим к тому, что связанность (coupling) и прочность (или связность, cohesion) — это про примерно одно и то же, и может возникнуть недоумение — почему тогда одно из этого — хорошо, а другое — почему-то плохо? :) Давайте разбираться.

Компоненты в большой сложной системе вложены друг в друга, и то, что являлось связанностью (скорее отрицательной характеристикой) на одном уровне — становится прочностью на следующем (т.к. становится внутренней связью компонента, а не внешней)!

В докладе расскажу о выведенном и предлагаемом мной принципе каскадного снижения связанности, на его примере поговорим о том, как в целом замерять архитектурные метрики, как понять, какие значения метрик хорошие и плохие, и как по ним проверять архитектуру на соблюдение принципов проектирования. Более того — поговорим о том, как все это (замер метрик и прогон тестов на принципы) автоматизировать.

Поделюсь ссылкой на свой Open Source-репозиторий с инструментами для измерения архитектурных метрик и покрытия архитектуры тестами (и приглашу всех стать контрибьюторами). И, надеюсь, добавлю в вашу копилку +1 принцип проектирования распределенных систем :)