Coupling

Coupling измеряет, насколько один модуль зависит от внутренностей другого. На интервью разбирают compile-time coupling (общие типы, библиотеки), runtime coupling (синхронные вызовы, shared database), data coupling (общие схемы), temporal coupling (согласованное время) и organizational coupling (команды, которые релизятся вместе).

Меньший coupling даёт независимые изменения, но увеличивает стоимость интеграции. Цель не нулевой coupling, а размещение связности на стабильных, явно владеемых границах.

На интервью: классифицируйте типы coupling на диаграмме, объясните, какие границы снижают change risk, и обоснуйте, где tight coupling допустим (например, внутри bounded context).

Типовые ошибки: coupling через общую БД; HTTP как иллюзия независимости; shared libraries, возвращающие монолитный release train.

Компромисс — гибкость против сложности: знайте, когда достаточно более простого пути.

Чеклист:

• Перечислите типы coupling в дизайне.
• Определите изменения, требующие coordinated releases.
• Предложите границы, поглощающие volatility.
• Допускайте intentional coupling только с ясным ownership.