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

Для понимания того, как модульность выглядит на уровне приложения обратимся к схеме:

Оранжевый и сиреневый квадраты — это модули Бизнес Логики(БЛ).
Зеленые линии — это тоже модули, но модули технические.

В контексте данной темы технические модули называют «слоями», а модули БЛ «модулями», так как чаще всего изменения и разработка касаются бизнес логики — добавляются новые фичи, изменяется поведение старых и тому подобное.

На схеме отображено взаимодействия модулей бизнес логики с техническими слоями приложения. Каждый модуль реализует собственную функциональность, используя возможности слоев БД, логики приложения(обмен сообщений, запуск фоновых задач, ...) через контракты(интерфейсы).

Мы можем изменить реализацию и способ хранения данных, но модуль «Orders» ничего не заметит, он как использовал нужные ему вызовы методов слоя БД, так и использует. Можем поменять визуальное представление сущностей модуля «Payments», модулю все равно, он отдает со своей стороны данные по контракту и получает объект-представление, как и было оговорено в контракте.

Модули БЛ добавляются, приложение растет, полезных действия приложения становится больше, и еще длительное время проект спокойно развивается в рамках такой архитектуры.