Архитектура Android-приложений… Правильный путь?

Решил, что «Архитекрута» — это не опечатка, а новый термин, определяющий крутую архитектуру.

Грамотно, но ничего нового. Рано или поздно любой разработчик приходит к модульной архитектуре. Тут главное не переабстрагироваться, а то можно для решения простейшей задачи написать огромный красивый фреймворк, но иногда это излишне. *картинка булки хлеба-тролейбуса*

Окей, с точки зрения потока данных все хорошо, вроде бы. Теперь предположим, что для пользователя у нас есть трек, в виде url, который по нажатию кнопки нужно проиграть, стримом. Проигрывание, естественно, выносится в сервис. Как это впишется в предложенную модель?

Как то сложно это, для 2 экранов создавать более 50 классов. Может для некоторых классов приложений это актуально, но для клиент-серверных приложений, в которых вся логика, как правило, находится на сервере это уж слишком.

Главное — помнить, что андроид может убить твое приложение в процессе выполнения долгой задачи (загрузка данных в сервисе и т.д.)
Необходимо реализовать механизм восстановления процесса получения этих данных, если необходимо.
Также важно выполнять все долгие операции в фоновых потоках (работа с базой, причем все типы запросов и т.д.)
Даже банальное отображение картинки может выглядеть так:

//абстрактный пример
if (!tryGetImageFromMemory()) {
	if (!tryGetImageFromFileCache()) {
		tryGetImageFromInternet();
	}
}

А как автор планирует держать модель в памяти, чтобы к ней могли обращаться все констроллеры (MVC)? Стоит ли использовать для этого шаблон Одиночка?

"Правило Зависимостей: код должен иметь зависимости только во внутренние круги и не должен иметь никакого понятия, что происходит во внешних кругах. "

Тогда почему в данном примере Data Layer знает о Domain Layer? Знает о модели данных Domain Layer, реализует некоторые интерфейсы. Следуя правилу зависимостей нужно что бы Data Layer предоставлял интерфейс для получения данных, который будет использоваться в Domain Layer.