Почему нельзя писать монолитные приложения без чистой архитектуры
Что проверяют
Умеете ли вы обосновывать архитектуру, а не пересказывать схему со слоями. Вопрос провокационный: хороший ответ содержит и довод за разделение, и границу, за которой оно начинает мешать.
Как отвечать
Сначала уточните термин: монолитом в Android называют не то, что на бэкенде. Речь про экран, где запрос в сеть, разбор ответа, бизнес-правила и работа с вью лежат в одном классе, и про проект из одного Gradle-модуля.
Конкретные беды такого кода:
- логику не проверить обычным юнит-тестом, она завязана на жизненный цикл и классы фреймворка, тесты уезжают в инструментальные и идут минутами;
- состояние живёт во вью, поэтому поворот и смерть процесса ломают экран, и каждый случай чинят отдельной заплаткой;
- правка одной строки пересобирает весь модуль;
- переезд на Compose или смена сетевого слоя превращаются в переписывание экрана целиком, потому что подменить нечего.
Чистая архитектура отвечает на это правилом зависимостей: слой данных и слой представления знают про домен, домен не знает ни про кого. Тогда бизнес-правила это обычные классы на JVM, а интерфейс и сеть подменяемы.
Сразу назовите цену. На маленьком экране три набора моделей с мапперами и отдельный класс на каждое действие дают больше кода, чем пользы. Границы проводят там, где есть что защищать: сложные правила, несколько источников данных, работа нескольких команд.
Где спотыкаются
Перечисляют слои и правило зависимостей, но не могут сказать, какую боль это закрыло в их проекте. Ответ звучит пересказом статьи, и следующий вопрос обычно добивает.
Второе: путают деление на Gradle-модули с делением на слои. Модули ускоряют сборку и запрещают лишние импорты, слои задают направление зависимостей. Одно бывает без другого.
Третье: доводят до абсурда, заводят интерфейс на каждый класс с единственной реализацией и обёртку, которая просто зовёт репозиторий. Тестируемость от этого не растёт, а время сборки и число файлов растут заметно.