В чем разница каплинга и кохезии в архитектуре
Что проверяют
Умеете ли вы оценивать границы модулей и сервисов не на глаз, а по понятным критериям. Системному аналитику это нужно при нарезке сервисов, проектировании интеграций и API. Следом обычно просят пример: где в вашей системе связи между частями были слишком сильными и во что это обходилось.
Как отвечать
Начните с двух определений и того, как они связаны:
- каплинг (coupling, зацепление): насколько модули зависят друг от друга. Чем он ниже, тем реже изменение в одном месте расходится волной по всей системе;
- кохезия (cohesion, связность): насколько элементы внутри одного модуля работают на одну задачу. Высокая кохезия значит, что у модуля одна понятная ответственность.
Цель формулируется парой: низкий каплинг между модулями, высокая кохезия внутри. Это две стороны одного решения о границах. Если то, что меняется вместе, лежит в одном модуле, то и зависимостей между модулями становится меньше.
Дальше переведите это на язык аналитика:
- общая база на несколько сервисов: сильный каплинг, переименование колонки ломает соседей;
- синхронная цепочка вызовов: сервис A не отвечает, пока не ответят B и C. Асинхронные события через брокер ослабляют связь по времени;
- контракт API: версионирование и обратная совместимость убирают зависимость от чужих внутренностей;
- bounded context из DDD: способ добиться кохезии, собрав в один сервис всё, что относится к одной предметной области, например «оплаты» отдельно от «каталога».
Хорошо добавить признак, по которому проблема видна на практике: если одна бизнес-задача требует синхронного релиза трёх сервисов, границы проведены неудачно.
Где спотыкаются
Путают термины местами или считают, что оба показателя нужно повышать. Каплинг снижают, кохезию повышают.
Думают, что микросервисы сами по себе дают низкий каплинг. Нарезка по техническим слоям, а не по предметной области, даёт распределённый монолит: те же зависимости, только теперь по сети.
Стремятся к нулевой связанности. Модули всё равно взаимодействуют, задача в том, чтобы связь шла через стабильный и явный контракт, а не через общие таблицы и знание чужой реализации.