👍 🧩 Про модуляризацию и границы между фичами
Чтение выходного дня натолкнуло на статью "Building Modular and Scalable iOS Apps".

Не сказать, что она очень подробная, но она поднимает важные темы:
- слоистость архитектуры,
- правила взаимодействия между модулями,
- DI и тестирование в контексте модульной структуры.

Я несколько лет назад писал цикл статей про модуляризацию — вот одна из них:
Там я подробнее разбирал вопросы, связанные с build critical path, графом зависимостей, подходом API/Impl, и тем, как всё это влияет на скорость сборки и масштабируемость архитектуры.

Интересно наблюдать, что тема модульной архитектуры всё ещё обсуждается (где-то даже очень базово).
И периодически появляются новые ракурсы размышлений (в комьюнити):
- развитие Tuist-а
- апдейты в Xcode
- интеграции с современными инструментами сборки и автоматизации.

#L #Arch #Modularity #apiimpl

👏

😄 Что такое модульность и когда она нужна?

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

Каждый модуль имеет публичный интерфейс, скрывает внутреннюю реализацию и может эволюционировать независимо.

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

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

Проектирование структуры до написания кода

Архитектуру стоит продумывать до начала реализации, а не по ходу роста проекта.

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

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

Три основные категории модулей

🛠️ Foundation-модули содержат общие модели, примитивы, инфраструктурные компоненты. Они не зависят ни от чего выше по иерархии и используются практически везде. Также они не должны содержать пользовательские сценарии.

🧰 Service-модули содержат переиспользуемую логику и сервисы. Они зависят от Foundation и используются фичами. Foundation-модули никогда не должны зависеть от Service-модулей, это нарушает иерархию.

🚚 Feature-модули содержат пользовательские сценарии (онбординг, оплата, профиль и т. д.). Они могут зависеть от Foundation и Services, но не должны зависеть друг от друга. Горизонтальные связи между фичами быстро разрушают архитектуру и возвращают монолитные проблемы.

Модульность ради модульности

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

Хотя определенные плюсы все равно будут присутствовать. Будет меньше конфликтов на мержах и ускорится параллельная разработка.

📎 Modularity as an Architectural Choice

#D #Arch #Modularity #Clean

👏

😄 Контракты модулей и контроль публичного 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

👏