График зависимостей чистой архитектуры (многомодуль)

В "традиционной" чистой архитектуре нет "данных", есть сущности:

Как видите, поток presentation -> use cases -> сущности.

А уровень доступа к данным находится на уровне инфраструктуры (фреймворк/драйверы) (см. БД на схеме).

То, что предлагает Google, больше похоже на Традиционную «N-слойную» архитектуру приложения.

У них есть разные плюсы и минусы, и о них есть много ответов/блогов:

• В чем разница между чистой и многоуровневой архитектурой?
• Лук против N-слойной архитектуры
• Сравнение трехуровневой и чистой архитектуры для веб-разработки

Обычно N-уровневая архитектура немного проще, менее церемониальна и больше подходит для «меньших» проектов/команд. Для многофункциональных проектов и/или больших команд обычно более рекомендуется чистая архитектура.

Моё личное понимание обоих паттернов таково, что это не эксклюзив или если вы сталкиваетесь с их направленностью.

Чистая архитектура фокусируется на графе зависимостей:

• никакие сущности или внутренние элементы домена не должны импортировать внешние слои
• это помогает вашей бизнес-логике оставаться независимой от фреймворков или даже языков программирования.

Android Layer-Pattern уделяет большое внимание DataFlow:

• представление не должно напрямую обращаться к уровню данных (например, в более крупных приложениях абстракцию следует добавлять через уровень домена)
• это помогает сохранить независимость вашего пользовательского интерфейса от внешних изменений интерфейса.

Различия в организации кода могут быть более очевидными. Модуль данных, о котором идет речь в Android Layer-Pattern, может быть размещен во внешнем круге CleanArchitecture. Согласно правилам шаблона слоев Android, модуль пользовательского интерфейса (который остается в том же круге) не должен иметь доступ к модулю данных.

В нашей команде мы стараемся использовать оба подхода как лучший стандарт для наших более крупных проектов.

1. мы хотим следовать стандарту Google, чтобы новым разработчикам было легче адаптироваться
2. Мы также хотим воспользоваться преимуществами потери бизнес-логики, которую должно быть легко поддерживать при обновлениях инфраструктуры и
3. самое главное, мы хотим тестировать наши доменные части независимо и автоматически с высоким процентом (>90%) LOC и покрытия ветвей.

Ключом к достижению этого является использование DependencyInversion на внутренних слоях (домене). Для реализации этого в большой команде полезно использовать gradle-modularization и konsit-tests (выполняемые через junit-framework), которые также голосуют в автоматических CI-тестах.