Комментарии 7
А где конкретно Google рекомендует Clean Architecture? Их гайды по архитектуре отличаются от принципов Clean Architecture. Ни Clean ни имя автора нигде не упоминается.
Содержит бизнес‑логику, должен быть независим от деталей реализации приложения и внешних библиотек (можно делать исключения, пример RxJava, DI Framework)
Можно делать исключение в случае если это языковые либы, например для того же DI если вы используете Koin или для асинхронщины Kotlin Coroutines.
Не совсем корректно то что в domain модуль имплементируется зависимость Hilt так как она напрямую из Android, а domain модуль не должен зависить ни коим образом от платформенных зависимостей и должен быть чисто языковым модулем Java/Kotlin, так как вам нужны тот же @Inject @Singleton , а Hilt поддерживает JSR-330, правильнее будет использовать зависимость Javax.Inject и так же DI module'и мне кажется правильнее выносить в какой di модуль либо в ту же app'ку, так как di не ответственность этих модулей, собственно в остальном все по теме) ??
Если будет полезно можете заглянуть сюда по реализации clean'a стараюсь частенько его обновлять
Согласен, di не в доменном слое должен быть. И не в других слоях тоже, а вообще отдельно. Бизнес-логика не должна иметь никаких зависимостей от классов других слоёв, а если мы включим в неё di, то зависимости будут.
На мой взгляд немного странный совет "Избегайте монотонного использования одного и того же паттерна или подхода во всем приложении, так как это может нанести вред", разве не в этом суть как раз таки стандартизации и шаблонов? Если используем паттерн на весь проект - то только его и используем, иначе например у новых подключившихся к проекту разработчиков могут возникнуть вопросы, наподобии "почему здесь так, а тут не так"?
Просто об архитектуре в Android