😄 Контракты модулей и контроль публичного API

У каждого модуля должен быть явно определен контракт:

🛠️ В Foundation-модулях допустим широкий API, но изменения будут дороже.

🧰 В Service-модулях API должен быть узким и сфокусированным, его рост является сигнал о "божественной" ответственности.

🚚 В Feature-модулях должен быть минимальный интерфейс: точка входа и результат выполнения сценария.

Навигация и взаимодействие между фичами

Внутренняя навигация это ответственность самой фичи. Переходы между фичами не должны происходить напрямую. Часто они выносятся во внешний координатор (AppCoordinator, TabCoordinator и т. д.).

Фича сигнализирует о завершении сценария, а координатор решает куда идти дальше и передает данные следующей фиче. Это сохраняет изоляцию и прозрачность зависимостей.

Сборка фич и обмен данными

Координатор не должен собирать внутренности фичи. Каждая фича сама знает, какие зависимости ей нужны и предоставляет assembly API (factory, builder и т.п). Обмен данными происходит через result-модели, а при наличии общих моделей, они выносятся в отдельный нейтральный модуль.

Для сложного взаимодействия возможен mediator-модуль, который знает о нескольких фичах, управляет их взаимодействием. Такой подход используется реже из-за архитектурной сложности.

Протокольные bridge-модули

Bridge-модули на протоколах выглядят красиво с точки зрения чистой архитектуры, но увеличивают количество модулей, время сборки и когнитивную нагрузку. Часто они создают иллюзию слабой связанности.

Они оправданы в конкретных случаях где требуется изоляция тяжелых зависимостей, тестирование или постепенный переход от монолита. Внутри фич протоколы допустимы, но стоит иметь во внимании, что гипергибкость почти никогда не окупается.

Какие выводы можно сделать?

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

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

📎 Modularity as an Architectural Choice

#D #Arch #Modularity #Clean

👏