Архитектура Android-приложения
Вопрос
Опиши, какую архитектуру ты бы выбрал для нового приложения среднего размера и почему.
Попробуйте сами
Ответьте вслух за 2 минуты, как на собесе. Потом сверьтесь с тезисами: что прозвучало, а что нет.
Показать ответ и разбор
Коротко
Что должно прозвучать в ответе
Слои UI, необязательный domain, data по гайду Android
UDF: один UiState на экран, действия методами или sealed-интентами
Единый источник правды: Room, сеть обновляет базу
DI через Hilt, интерфейсы репозиториев
Модули по фичам и core, по мере роста
Use case только при реальной логике, без лишних мапперов
Что могут спросить следом
- Как организовать навигацию между feature-модулями?
- Как обрабатывать ошибки сквозь слои?
- Как бы ты мигрировал легаси-приложение?
Разбор
Беру за основу рекомендованную Google архитектуру. UI на Compose, у каждого экрана ViewModel с одним StateFlow<UiState>, действия приходят методами или sealed-интентами, то есть фактически MVVM с элементами MVI и строгим однонаправленным потоком данных. Data-слой из репозиториев с единым источником правды: если приложению нужен офлайн, это Room, а сеть только обновляет базу, и UI видит изменения через Flow. Domain-слой ввожу точечно, когда логика переиспользуется несколькими экранами или сложна, use case-прокладки не пложу. Зависимости через Hilt, ViewModel видит интерфейсы репозиториев, поэтому в тестах подменяю их фейками. Ошибки превращаю в доменные результаты в data-слое, а ViewModel переводит их в состояние экрана. Пока проект небольшой, хватает модулей app, core и пары фич; по мере роста команды разбиваю по фичам, чтобы ускорить сборку и развести зоны ответственности. Одноразовые события делаю частью состояния или через Channel.
Ответьте сами, а не прочитайте
В тренажёре вопрос попадёт в повторения и вернётся, когда начнёт забываться. Плюс билеты с зачётом: 20 вопросов, не больше 2 ошибок.