Они же cohesion и coupling, тяжело подобрать перевод получше. Первый термин — про то, насколько близки элементы внутри модуля (например, все связанное с пользователем в одном модуле, а все с его заказами — в другом), второй — про количество связей между модулями (негоже сервису заказов лезь напрямик в БД пользователей). Считается, что в идеале должен быть сильный фокус и низкая связанность, однако только ситхи возводят все в абсолют и надо знать меру. Подробнее можно почитать в этой годной статье.

Очень много архитектурных паттернов, по сути, стремятся достигнуть идеала. Можно сказать, что микросервисы, акторы, чистое ядро, хексагональная архитектура, слоеная/луковая архитектура и т.д. — это все попытки решения этой проблемы.

Про все это можно еще послушать в этом докладе. Там есть еще интересный взгляд на Spring: классическое разделение на контроллер, сервис, репозиторий с интерфейсами — это по сути хексагональная архитектура, и одна из киллер-фич Spring в свое время была возможность инъекции зависимостей и тестирование с моками (а тестирование на серверах приложений было неудобным). Одна из основных идей заключается в том, что функциональная структура важнее технической, и если у вас домен фигово разделен, то архитектура не поможет. Помимо теории, в нем есть еще и практика: как разбить все по папкам (но до уровня удушения этой статьи докладчику далеко) и как IDE может помочь с пониманием проекта. Прагматизм еще выражается в том, что не так уж и важно, что там внутри модуля, и ничего криминального в том, чтобы прямо из REST-контроллера вызвать соединение к базе, если модуль очень маленький.