Какие принципы и паттерны учитываются при проектировании архитектуры, например чистая архитектура или луковая?

Что проверяют

Понимаете ли вы, что архитектура приложения и архитектура экрана это разные уровни. Следом обычно спрашивают, как у вас отделён домен от UIKit, SwiftUI и сети и как вы проверяете, что эту границу никто не нарушил.

Как отвечать

Чистая, луковая и гексагональная архитектура держатся на одном правиле: зависимости направлены внутрь, к бизнес-логике, а она не знает про фреймворки. Разница между ними в основном в названиях слоёв.

• Domain: сущности и use cases на чистом Swift, без импорта UIKit, SwiftUI, CoreData и сетевых библиотек. Здесь же протоколы репозиториев;
• Data: реализации этих протоколов, URLSession, Core Data или SwiftData, кеш, маппинг DTO в доменные модели;
• Presentation: экраны и их логика. Здесь живёт MVVM, VIPER или TCA, то есть архитектура экрана встраивается во внешний слой, а не заменяет чистую;
• сборка: зависимости передаются через инициализатор и собираются в корне приложения или в DI-контейнере.

Сильный ход: рассказать, как границу проверяет компилятор. Если вынести Domain в отдельный модуль Swift Package Manager без зависимостей от других модулей, импорт UIKit туда просто не соберётся. Это надёжнее договорённостей в команде.

Из паттернов уместно назвать Repository, внедрение зависимостей через протоколы, Coordinator для навигации, из SOLID прежде всего DIP. Протоколы на границах дают тестируемость: ViewModel и use case проверяются с моками, без сети и без запуска интерфейса.

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

Где спотыкаются

Путают Clean Architecture с Clean Swift (VIP). Второе это схема для одного экрана, с чистой архитектурой её роднит только название.

Используют NSManagedObject как доменную модель. Тогда Core Data протекает во все слои, а смена хранилища превращается в переписывание приложения.

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