Как реализовать чистую архитектуру на Android?

ИМХО, такой подход примирителен к любому приложению с пользовательским интерфейсом.
Не понимаю каким боком тут андроид указан…

А ради чего ошибки преобразуются в магические константы? Можно ведь более внятные решения использовать, вроде Throwable наследований или Sealed классов.
Это же любой разработчик забодается определять, что же там внури за ошибка, если проект хоть немного разрастется.

В целом получилось интересно, но создалось ощущение, что чистая архитектура это только про слои. А пример пакетов вообще вводит в заблуждение, ведь даже сам Мартин говорил, что в чистой архитектуре по структуре проекта должно быть понятно, что он делает и какие фичи имеет, а не какие паттерны и архитектуры были применены. Такая структура пакетов должна быть внутри пакета конкретной фичи, как ты смотришь на такой вариант?

Спасибо за статью на интересную тему.
[далее замечания, но не для критики статьи]
Зона ответственности, как термин постоянно требует уточнения. [Не знаю почему. ] Обычно ее понимают как, «одна сущность делает, что-то одно», но это понятие связано сильно с вектором изменением. Есть даже определение у каждого класса/компонента и т.д. только один владелец. Или каждый класс должен иметь один вектор изменения.
Так вот. Самое интересное. Разработчик разбил на слои и компоненты свой проект и получает глубокое удовлетворение и счастье когда ему приходят требования тз совпадающие с вектором изменения, который заложен в проекте (т.е. с архитектурой). Но в реальности действует закон «Вектор изменения предполагаемый разработчиком строго перпендикулярный вектору изменения требуемого заказчиком». И здесь наша архитектура плывет.
Для примера.
Аналогия со сборкой машины. Там где делают колеса. Заказчик прислал ТЗ «сделать диаметр колес в два раза больше». В идеале, это изменение никак не должно затронуть другие цеха. Мы сделали новые колеса и их просто поставили. Это хорошая архитектура. Если потребовалось изменение в других компонентах (например кузова) — похуже.
Еще пример.
Заказчик прислал тз. наше приложение вышло на рынок под маркой «PoBuhay» и требуется подключить еще несовершеннолетних клиентов. С показом газировки (с указанием размера пузырьков). И если мы тапаем на газировку, открывается вьюха с Пяточком с подгрузкой данных по количество калорий и газа. Т.е новый элемент (прям очень) отличается от тех которых мы задумали первоначально. Изменения пройдут по всем слоям. И желательно сделать такие изменения, что при добавление других новых элементов это затронет как можно меньше слоев и классов. Улучшить архитектуру, сделать ее гибче.
Делая архитектуру гибче, мы ее делаем менее понятной. И все выливается в поиск баланса и вопросу «серебряная пуля vs незатратный проект»