У вас никогда не вызывало недоумения, что связанность (coupling) и прочность (или связность, cohesion) — это про примерно одно и то же, но одно — хорошо, а другое — почему-то плохо? Компоненты в большой сложной системе вложены друг в друга, и то, что являлось связанностью (скорее отрицательной характеристикой) на одном уровне — становится прочностью на следующем (т.к. становится внутренней связью компонента, а не внешней)!
Даже если взять микросервис, как единицу гранулярности — слоёв над ним может быть несколько:
А в больших продуктах и компаниях системы могут делиться на подсистемы или проекты, enterprise уровень разделяется на архитектуру домена и междоменный ландшафт, а ещё добавляется слой или слои платформизации...
Сложность систем и компаний растёт, а стандартный приём борьбы со сложностью — это увеличение слоёв абстракции. Таким образом компонентизация архитектуры — это нормальный процесс, где количество уровней ничем не ограничивается.
При таком раскладе уже недостаточно стандартного разделения на архитектуру и архитекторов решений и предприятия (solution и enterprise), либо наоборот — грань этого разделения стирается.
Логичным выводом будет переход от бинарного деления на связанность и прочность к цепочке зависимостей:
Микросервисы → Контексты микросервисов → Продукты → Архитектура предприятия.
Звеньев в такой цепочке на самом деле может быть сколько угодно. И для таких цепочек сформулируем новое правило взамен низкой связанности и высокой прочности:
Мера зависимостей между элементами каждого последующего уровня должна быть не выше, чем у предыдущего.
В докладе расскажу подробнее и разберу на примерах новый предлагаемый мной новый принцип (или правило) проектирования архитектур — принцип каскадного падения связанности.
Любой уровень.
Соучредитель, технический директор, ИТ-архитектор в Бындюсофт. Автор и преподаватель курса по микросервисной архитектуре в ИТМО.
Член программных комитетов CodeFest, TechLeadConf и UWDC.
