# Связанность и связность: как не собрать IT-монолит Canonical: https://www.kt-team.ru/blog/coupling-cohesion-and-it-monoliths Source: https://www.kt-team.ru/blog/coupling-cohesion-and-it-monoliths Canonical URL: https://www.kt-team.ru/blog/coupling-cohesion-and-it-monoliths Original URI: /blog/coupling-cohesion-and-it-monoliths ## SEO / GEO Metadata - Title: Связанность и связность: как не собрать IT-монолит - Description: Что такое связанность и связность, чем сильная связанность превращает системы в монолит и как слабо связанная архитектура на ESB делает бизнес гибким. - Canonical: https://www.kt-team.ru/blog/coupling-cohesion-and-it-monoliths - Robots: not specified - Open Graph tags: 4 - Twitter tags: 4 - JSON-LD blocks: 3 ## Article Связанность (coupling) — это степень взаимозависимости модулей и систем, а связность (cohesion) — то, насколько согласованы задачи внутри одного модуля. Гибкая ИТ-архитектура держится на простом сочетании: слабая связанность между сервисами и сильная связность внутри каждого. Когда наоборот — системы знают слишком много друг о друге, любое изменение тянет за собой цепочку правок, и контур превращается в IT-монолит: дорогой в поддержке и медленный в развитии. Разбираем, чем отличаются сильная и слабая связанность, при чём здесь общий контекст предприятия и по каким признакам отличить слабо связанную (loosely coupled) архитектуру от монолита. ## Коротко - Связанность — это зависимость между модулями, связность — согласованность задач внутри модуля. Цель — слабая связанность и сильная связность. - Сильная связанность («точка-точка») превращает контур в IT-монолит: правки тянут цепочку изменений, растёт нагрузка на senior-инженеров. - Слабо связанная (loosely coupled) архитектура даёт быструю масштабируемость, отказоустойчивость, простой мониторинг и защиту от вендорлока. - Инкапсуляция: каждый сервис отвечает только за свои данные в общем контексте предприятия и знает о соседях минимум. - Сервисная шина (ESB) и брокеры сообщений — инструменты, которыми слабая связанность реализуется на практике. > Слева каждая система связана с каждой напрямую: число связей растёт квадратично, любое изменение задевает соседей. Справа системы обмениваются через общий контекст (шину) — каждая знает о других минимум и меняется независимо. ## Связанность, связность и инкапсуляция Идеал — слабая связанность между модулями и сильная связность внутри: небольшое число внешних связей и близкие по смыслу задачи в одном модуле. ### Связанность (coupling) Мера взаимозависимости модулей. Сильная связанность (high coupling) — модули знают слишком много друг о друге, их сложнее менять и тестировать; это признак монолита. Слабая (low coupling) — изменение в одном модуле не требует правок в других. ### Связность (cohesion) Насколько согласованы задачи внутри одного модуля. Сильная связность (high cohesion) — модуль решает близкие по смыслу задачи и не разрастается, и это хорошо. Слабая — один модуль тащит разнородные обязанности, его тяжело понимать и поддерживать. ### Инкапсуляция Детали реализации спрятаны внутри сервиса: он пользуется только тем, что доступно по контракту, и не лезет внутрь соседа. Чем меньше предположений сервисы делают друг о друге (принцип Дэвида Парнаса), тем легче менять одну часть, не трогая другую. ## При чём здесь общий контекст предприятия В разработке есть два контекста — приложения и предприятия. Заказ в CRM и в интернет-магазине — разные сущности: контексту предприятия о заказе важны только идентификатор, клиент и сумма, остальные атрибуты CRM ему не нужны. При сильной связанности каждая система, чтобы обменяться данными, должна знать внутренний контекст другой — контексты перемешиваются, интеграции превращаются в «точку-точку», а контур становится монолитом. При слабой связанности каждая система «думает», что она одна на предприятии, и отвечает только за то, что сама передаёт в общий контекст. Сервисная шина (ESB) — инструмент, который реализует такой обмен. ## Признаки слабо связанной архитектуры ### Быстрая масштабируемость Новый сервис добавляется, не затрагивая остальные: они не знают, что в общий контекст что-то добавили, и продолжают вести свой бэклог. ### Отказоустойчивость Ошибки инкапсулированы за счёт малого числа связей. При отказе одного потока остальные работают, система держит пиковые нагрузки. ### Простой мониторинг Разобраться в связях может не только перегруженный senior: мониторинг делегируется поддержке, а на превышение параметров ставятся автоматические алерты. ### Высокая скорость изменений Доработка одного сервиса не ломает остальные, а новые потоки данных запускаются быстро — меньше упущенной выгоды. ### Актуальность данных Каждая система отвечает только за свои данные в общем контексте, без перевода запросов в чужой контекст и связанных с этим потерь и ошибок. ### Защита от вендорлока Сервис можно заменить или доработать, не переписывая интеграции; их можно отдать любому разработчику или подрядчику. ## Как KT.Team разбирает монолит на слабо связанные сервисы KT.Team 13 лет проектирует слабо связанные интеграции для среднего и крупного бизнеса. Несколько примеров из практики (кейсы — в разделе [кейсы](/cases)): ### Enterprise-проект Интеграции «точка-точка» заменили лёгким обменом сообщениями через Kafka — системы стали слабосвязанными, любую можно убрать или заменить без переделки остальных. ### Крупный ритейлер Единый контракт сообщения и общий API для 200+ систем 1С — новая торговая точка подключается копированием компонента, без новой разработки, а интеграции стали отказоустойчивыми и прозрачными за счёт мониторинга. ### Производитель оборудования Спроектировали целевую схему и запустили 48 потоков обмена данными — новая карта интеграций обеспечила слабую связанность и высокую отказоустойчивость. ## Частые вопросы о связанности и связности **Чем связанность отличается от связности?** Связанность (coupling) описывает зависимость между разными модулями и системами, связность (cohesion) — согласованность задач внутри одного модуля. Хорошая архитектура — это слабая связанность между модулями и сильная связность внутри каждого. **Как понять, что у нас IT-монолит?** Признаки монолита: изменение в одной системе тянет за собой правки в нескольких других, интеграции сделаны «точка-точка», разобраться в связях может только один перегруженный senior, а релизы всё чаще срываются из-за кросс-командного тестирования. **Что даёт переход к слабо связанной архитектуре?** Быстрое подключение новых систем, отказоустойчивость, простой мониторинг, актуальность данных и защиту от вендорлока: сервисы меняются независимо друг от друга, не ломая соседей. **Микросервисы для этого обязательны?** Нет. Слабая связанность достигается и на сервисной шине (ESB), и на брокере сообщений, и в модульном монолите с чёткими контрактами. Важна не мода на микросервисы, а границы модулей и минимум предположений сервисов друг о друге. **С чего начать размоноличивание?** С карты интеграций и контекста предприятия: какие данные каждая система обязана отдавать в общий контекст. Дальше обмен «точка-точка» заменяют передачей через шину или брокер, оставляя каждому сервису ответственность только за свои данные. ## От теории к вашему контуру Разберём вашу карту интеграций и покажем, где контур превращается в монолит. KT.Team проектирует и внедряет [интеграционную шину (ESB)](/solutions/enterprise-service-bus) — n8n, DATAREON, Kafka — и переводит обмен «точка-точка» на слабо связанную архитектуру.