А код будет?

Такого требования вобщем-то не существует. Поэтому слово "должна" я-бы смягчил. Скорее модульность
логически вытекает из закона Деметры для крупных проектов. Модульность это не прихоть. Это вынужденная
необходимость.

Повезёт-ли вам использовать такие проекты или быть их разработчиком - я не знаю. Но заранее сочувствую.
В них обычно нет единого эксперта которые знает все. Особо крупные системы для ентерпрайза (бизнес и финансы)
пишут по 15-20 лет и в них сменяется поколение разработчиков и newcomers просто в принципе не могут знать
эту систему целиком. Обычно скрам-команда делает поддержку и доработку какого-то куска этой системы.
И эта команда знает функционал своего куска и видит интерфейсы используемых модулей. И на этом точка.
Знать всё или следить за изменением всей системы в динамике просто невозможно. На это не хватит человеческого
мозга. Коммиты идут каждый день потоком. И дай бох просто осознать свой модуль.

А если смотреть на модульность например в системных консольных утилитах linux, то там скорее всего такая
модульность будет не ярко выражена и доказать ее наличие будет сложно.

В разных ЯП и разных средах в термин модуль вкладывали разный смысл. Например в Oracle PL/SQL
модуль (package) инстанциировался. У него был конструктор или процедура которая что-то делает при инциализации.
В Pascal - нечто подобное. Тоесть модуль можно рассматривать как компонент или как объект с состоянием.

В других системах модуль может быть просто логическим объединением функций. Или например в технологии
OSGI модуль наполнен смыслом инфо-безопасности. Тоесть на уровне платформы вы могли использовать только
регламентированные методы интерфейса или протокола модуля и никоим образом не могли вызвать внутренний код.
Эти модули также несли задачи непрерывной интеграции и версионности. Среда позволяла одновременно держать
в памяти два модуля разных версий (полезно во время миграции) и таким образом для пользователя апргрейд
версии был прозрачен и безобрывен.

К сожалению в последнее время для современных разработчиков модульность - гипертрофирована. Начинающие
делают декомпозицию на модули для своих задач там где она вообще не нужна. Таким образом появляется
много карго-культа и нарушений KISS/Yagni.

Может. Но я-бы начал с задачи-минимум. Представте работу с сущностью в виде объекта.

А потом если возможностей не хватит и у вас реально (!) появятся эти ужасные архитектурные
проблемы о которых так любят говорить архитекторы - перепишите на модули.

Но начните с простого.

Что такое User controls в терминах форума C++?

Я пожалуй введу модераторское правило закрывать топики C++, которые не имеют исходника в своей основе.

Все что не имеет исходника будет перенесено в вопрос-ответ или в программирование. Или просто закрыто.