Что такое чистая архитектура и как она устроена?
Что проверяют
Понимаете ли вы правило зависимостей или просто перечисляете названия слоёв.
Как отвечать
Смысл в одном правиле: зависимости направлены только внутрь. Внутренние слои ничего не знают о внешних.
Слои от центра наружу:
- сущности: предметные модели и правила, которые верны независимо от приложения;
- сценарии использования: что система делает, оркестровка сущностей. Здесь же интерфейсы репозиториев, но не реализации;
- адаптеры: презентеры, ViewModel, реализации репозиториев, отображение моделей;
- инфраструктура: сеть, база, интерфейс, фреймворки.
Ключевой приём это инверсия зависимостей. Сценарию нужен доступ к данным, поэтому интерфейс объявляется в слое сценария, а реализация лежит снаружи и внедряется. Стрелка кода смотрит внутрь, хотя поток выполнения идёт наружу.
Что это даёт: предметная логика тестируется без Android, базы и сети; замена источника данных не трогает сценарии; фреймворк остаётся деталью.
В Android это обычно три модуля: domain (чистый Kotlin, без зависимостей от платформы), data (репозитории, Retrofit, Room), presentation (Compose и ViewModel). Сборка графа через Hilt.
Честно про цену: слоёв и отображений становится больше, на простом экране это лишняя работа. Оправдано там, где логика живёт долго и меняется чаще, чем инфраструктура.
Где спотыкаются
Называют слои, но допускают импорт Android в domain, чем ломают всё правило.
Считают чистую архитектуру обязательной для любого приложения.
Заводят отдельную модель на каждый слой без нужды и получают три одинаковых класса.
Не могут объяснить, зачем интерфейс репозитория объявлен в domain, а не в data.