Что такое связанность и связность, чем сильная связанность превращает системы в монолит и как слабо связанная архитектура на ESB делает бизнес гибким.
Связанность (coupling) - это степень взаимозависимости модулей и систем, а связность (cohesion) - то, насколько согласованы задачи внутри одного модуля. Гибкая ИТ-архитектура держится на простом сочетании: слабая связанность между сервисами и сильная связность внутри каждого. Когда наоборот - системы знают слишком много друг о друге, любое изменение тянет за собой цепочку правок, и контур превращается в IT-монолит: дорогой в поддержке и медленный в развитии.
Разбираем, чем отличаются сильная и слабая связанность, при чём здесь общий контекст предприятия и по каким признакам отличить слабо связанную (loosely coupled) архитектуру от монолита.
Идеал - слабая связанность между модулями и сильная связность внутри: небольшое число внешних связей и близкие по смыслу задачи в одном модуле.
Мера взаимозависимости модулей. Сильная связанность (high coupling) - модули знают слишком много друг о друге, их сложнее менять и тестировать; это признак монолита. Слабая (low coupling) - изменение в одном модуле не требует правок в других.
Насколько согласованы задачи внутри одного модуля. Сильная связность (high cohesion) - модуль решает близкие по смыслу задачи и не разрастается, и это хорошо. Слабая - один модуль тащит разнородные обязанности, его тяжело понимать и поддерживать.
Детали реализации спрятаны внутри сервиса: он пользуется только тем, что доступно по контракту, и не лезет внутрь соседа. Чем меньше предположений сервисы делают друг о друге (принцип Дэвида Парнаса), тем легче менять одну часть, не трогая другую.
В разработке есть два контекста - приложения и предприятия.
Заказ в CRM и в интернет-магазине - разные сущности: контексту предприятия о заказе важны только идентификатор, клиент и сумма, остальные атрибуты CRM ему не нужны.
При сильной связанности каждая система, чтобы обменяться данными, должна знать внутренний контекст другой - контексты перемешиваются, интеграции превращаются в «точку-точку», а контур становится монолитом.
При слабой связанности каждая система «думает», что она одна на предприятии, и отвечает только за то, что сама передаёт в общий контекст.
Сервисная шина (ESB) - инструмент, который реализует такой обмен.
Новый сервис добавляется, не затрагивая остальные: они не знают, что в общий контекст что-то добавили, и продолжают вести свой бэклог.
Ошибки инкапсулированы за счёт малого числа связей. При отказе одного потока остальные работают, система держит пиковые нагрузки.
Разобраться в связях может не только перегруженный senior: мониторинг делегируется поддержке, а на превышение параметров ставятся автоматические алерты.
Доработка одного сервиса не ломает остальные, а новые потоки данных запускаются быстро - меньше упущенной выгоды.
Каждая система отвечает только за свои данные в общем контексте, без перевода запросов в чужой контекст и связанных с этим потерь и ошибок.
Сервис можно заменить или доработать, не переписывая интеграции; их можно отдать любому разработчику или подрядчику.
KT.Team 13 лет проектирует слабо связанные интеграции для среднего и крупного бизнеса. Несколько примеров из практики (кейсы - в разделе кейсы):
Интеграции «точка-точка» заменили лёгким обменом сообщениями через Kafka - системы стали слабосвязанными, любую можно убрать или заменить без переделки остальных.
Единый контракт сообщения и общий API для 200+ систем 1С - новая торговая точка подключается копированием компонента, без новой разработки, а интеграции стали отказоустойчивыми и прозрачными за счёт мониторинга.
Спроектировали целевую схему и запустили 48 потоков обмена данными - новая карта интеграций обеспечила слабую связанность и высокую отказоустойчивость.
FAQ
Связанность (coupling) описывает зависимость между разными модулями и системами, связность (cohesion) - согласованность задач внутри одного модуля. Хорошая архитектура - это слабая связанность между модулями и сильная связность внутри каждого.
Признаки монолита: изменение в одной системе тянет за собой правки в нескольких других, интеграции сделаны «точка-точка», разобраться в связях может только один перегруженный senior, а релизы всё чаще срываются из-за кросс-командного тестирования.
Быстрое подключение новых систем, отказоустойчивость, простой мониторинг, актуальность данных и защиту от вендорлока: сервисы меняются независимо друг от друга, не ломая соседей.
Нет. Слабая связанность достигается и на сервисной шине (ESB), и на брокере сообщений, и в модульном монолите с чёткими контрактами. Важна не мода на микросервисы, а границы модулей и минимум предположений сервисов друг о друге.
С карты интеграций и контекста предприятия: какие данные каждая система обязана отдавать в общий контекст. Дальше обмен «точка-точка» заменяют передачей через шину или брокер, оставляя каждому сервису ответственность только за свои данные.
