Хочу попробовать небольшой цикл про архитектуру iOS-приложений: начать с самых простых подходов и постепенно дойти до современных, а возможно, и немного экспериментальных.

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

Потому что архитектура почти всегда про обмен одной сложности на другую. Мы добавляем новые сущности и правила не потому, что «так положено», а потому что текущий подход перестаёт справляться с конкретной проблемой.

И начать логично с MVC.

В классическом виде всё довольно просто: Model — данные и логика. View — отображение. Controller — связывает одно с другим.

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

И здесь, на мой взгляд, важная вещь: простая архитектура — не плохая архитектура.

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

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

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

Правда, здесь легко уйти и в другую крайность: можно настолько хорошо всё разделить, что для изменения текста кнопки понадобится путешествие через восемь сущностей.

Проблемы MVC обычно начинаются как раз тогда, когда продукт растёт, а ответственность всё ещё остаётся внутри контроллера.

Сначала UIViewController просто показывает экран. Потом он начинает загружать данные, хранить состояние, проверять ввод, преобразовывать модели, обрабатывать ошибки, управлять переходами и отправлять аналитику. Ещё немного — и контроллер уже знает о продукте больше, чем половина команды. Так появляется знаменитый Massive View Controller.

Но дело даже не в тысяче строк. Гораздо важнее, что один объект начинает отвечать сразу за слишком разные вещи. Изменился способ получения данных — меняем контроллер. Поменялись правила проверки — меняем контроллер. Изменилась навигация — меняем контроллер. Добавили аналитику — ну вы поняли.

В какой-то момент становится сложно ответить на простой вопрос: а за что конкретно этот объект отвечает?

Именно здесь появляется реальная причина усложнять архитектуру. Не потому что MVC «плохой» или «устарел», а потому что текущего разделения ответственности уже недостаточно. Можно вынести принятие решений из контроллера. Отдельно управлять навигацией. Разделить работу с данными и представлением. Так постепенно появляются MVP, MVVM, Coordinator и более сложные подходы. Поэтому сегодня я бы не стал автоматически отказываться от MVC даже в новом проекте.

Если экран простой, логики немного, а сценарий понятный и локальный, дополнительные слои могут сделать код не лучше, а просто длиннее.

Иногда вместо архитектуры получается просто очень организованный способ передавать String через пять файлов.

Для меня хороший архитектурный вопрос звучит не так: «Какой паттерн здесь использовать?» А скорее: «Какая проблема текущего решения настолько серьёзна, что ради неё стоит добавить ещё один уровень архитектуры?»

Потому что хорошая архитектура не обязательно уменьшает количество сложности. Она старается разложить неизбежную сложность так, чтобы с ней было проще работать. Следующий шаг — MVP: что изменится, если забрать часть ответственности у контроллера и передать её отдельному объекту.