Cohesion

Cohesion отвечает на вопрос, принадлежат ли элементы внутри модуля друг другу — меняются по одной причине, разделяют инварианты или требуют одного owner для сохранения поведения. Высокий cohesion держит связанную логику рядом; низкий размазывает одну концепцию по слоям и сервисам.

В microservices и modular monoliths слабый cohesion проявляется в разбросанной валидации, дублированных business rules и «god services», владеющих несвязанными workflow. Сильный cohesion часто совпадает с bounded contexts, но требует дисциплины внутри каждого сервиса.

На интервью: критикуйте декомпозицию по cohesion, а не по именам папок. Объясните, когда разделение модуля улучшает ясность, а когда только добавляет network hops.

Типовые ошибки: разрез по CRUD-таблицам вместо business capabilities; выделение microservice до понимания domain model; низкий cohesion, замаскированный shared utility package.

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

Чеклист:

• Сформулируйте единую причину совместных изменений модуля.
• Проверьте дублирование инвариантов между сервисами.
• Колокализуйте правила с данными, которые они защищают.
• Объединяйте модули, которые всегда меняются вместе.