Clean Architecture в мобильном приложении
Вопрос
Расскажите, как устроены слои в вашем мобильном приложении и зачем.
Попробуйте сами
Ответьте вслух за 2 минуты, как на собесе. Потом сверьтесь с тезисами: что прозвучало, а что нет.
Показать ответ и разбор
Коротко
Что должно прозвучать в ответе
Presentation, domain, data и направление зависимостей внутрь
Интерфейсы репозиториев в домене, реализации в data, связывание через DI
Маппинг DTO и entity в доменные модели на границе
Ошибки переводятся в доменные на границе data
Use case только там, где есть логика или переиспользование
Слои внутри фич, а не глобальные папки
Что могут спросить следом
- Как вы тестируете каждый слой?
- Где граница между use case и view model?
Разбор
У нас три слоя внутри каждой фичи. Presentation: экраны и view model, которые знают только о состоянии и действиях. Domain: модели, бизнес-правила, интерфейсы репозиториев и use case там, где логика нетривиальна или нужна нескольким экранам. Data: реализации репозиториев, сеть, база, кеш и мапперы. Зависимости в коде направлены к домену: data реализует интерфейсы домена, а связываются они через DI. На границе data я маппю DTO и записи базы в доменные модели и перевожу технические ошибки в доменные. Тестирую так: домен чистыми юнит-тестами, view model с фейковыми репозиториями, data интеграционно с подменённым сервером. Use case-прокладки без логики не плодим: view model может вызвать репозиторий напрямую.
Ответьте сами, а не прочитайте
В тренажёре вопрос попадёт в повторения и вернётся, когда начнёт забываться. Плюс билеты с зачётом: 20 вопросов, не больше 2 ошибок.
Предыдущий вопрос
Код-ревью: use case оформления заказа (Swift)
Следующий вопрос
Когда не стоит делать Clean Architecture
Ещё по теме «Clean Architecture и слои»
- Правило зависимостей в Clean Architecture
- Что можно импортировать в domain-слой
- Зачем маппить DTO в доменные модели
- Ошибки на границах слоёв
- Пакеты по слоям или по фичам
- Инверсия зависимостей
- Слои мобильного приложения
- Сколько моделей нужно на сущность