Профессиональная конференция для Go-разработчиков

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

Архитектура

Микросервисы, SOA
Архитектурные паттерны
Распределенные системы
Методы и техника разработки ПО
Слабо связанная архитектура
Микросервисы

Доклад отклонён

Целевая аудитория

CTO, архитекторы всех уровней, техлиды, системные аналитики, бэкенд-разработчики, devops-инженеры

Тезисы

У вас никогда не вызывало недоумения, что связанность (coupling) и прочность (или связность, cohesion) — это про примерно одно и то же, но одно — хорошо, а другое — почему-то плохо? 🙂Компоненты в большой сложной системе вложены друг в друга, и то, что являлось связанностью (скорее отрицательной характеристикой) на одном уровне — становится прочностью на следующем (т.к. становится внутренней связью компонента, а не внешней)!
Даже если взять микросервис, как единицу гранулярности — слоёв над ним может быть несколько:
- ограниченный контекст микросервисов внутри продукта/системы
- продукт/система
- ландшафт предприятия (enterprise архитектура).
А в больших продуктах и компаниях системы могут делиться на подсистемы или проекты, enterprise уровень разделяется на архитектуру домена и междоменный ландшафт, а ещё добавляется слой или слои платформизации…
Сложность систем и компаний растёт, а стандартный приём борьбы со сложностью — это увеличение слоёв абстракции. Таким образом компонентизация архитектуры — это нормальный процесс, где количество уровней ничем не ограничивается.
При таком раскладе уже недостаточно стандартного разделения на архитектуру и архитекторов решений и предприятия (solution и enterprise), либо наоборот — грань этого разделения стирается.

Логичным выводом будет переход от бинарного деления на связанность и прочность к цепочке зависимостей:
Микросервисы → Контексты микросервисов → Продукты → Архитектура предприятия

Звеньев в такой цепочке на самом деле может быть сколько угодно. И для таких цепочек сформулируем новое правило взамен низкой связанности и высокой прочности:
Мера зависимостей между элементами каждого последующего уровня должна быть не выше, чем у предыдущего

В докладе расскажу подробнее и разберу на примерах новый предлагаемый мной новый принцип (или правило) проектирования архитектур — принцип каскадного падения связанности

Технический директор и архитектор Byndyusoft.
Автор и преподаватель курса по микросервисной архитектуре — ИТМО.
Член программных комитетов TechLeadConf и CodeFest.

Byndyusoft

Проектируют и разрабатывают IT-продукты под цели заказчика для e-commerce, ретейла, банков и других бизнесов по всему миру. Одни из лучших в стране по реализации высоконагруженных систем и микросервисной архитектуре.

Видео

Другие доклады секции

Архитектура