Kotlin Clean 架构
强大的基础架构对于一个应用扩展和满足用户群体的期望来说是非常重要的。我有一个用新更新和优化的 API 结构来替换旧 API 的任务，为了整合这种更改，我一定程度地重写了整个应用。
为什么？因为代码与其响应的数据模型（data models）深度耦合。这次，我不想一遍又一遍地犯同样的错误。为了解决这个问题，我使用了 Clean 架构。在一开始会有点痛苦，但对于具有许多功能和 SOLID 方法的大型应用来说可能是最佳选择。让我们试着带着疑问去看架构的每个层面，然后分解成更简单的点。
- news-sample-app: 创建 GitHub 账号来为本应用的开发做贡献
这个架构是由 Robert C. Martin（Uncle Bob）在 clean code blog 中于 2012 年提出的。
为什么是 Clean 架构？
- 在不同层级中分离具有特定职责的代码，让其更容易做进一步修改。
- 高度的抽象
- 代码解耦
- 轻松的代码测试
“整洁的代码总是看起来像是由在意它的人来写的。”
— Michael Feathers
有哪些层级？
Domain 层： 将执行独立于任何层级的业务逻辑，并且只是一个没有 Android 相关依赖的纯 kotlin 包。
Data 层： 通过实现 Domain 层的公开接口，将应用所需的数据分配给 Domain 层。
Presentation 层： 将包括 Domain 层和 Data 层，并且是 Android 特定的，用于执行 UI 逻辑。
什么是 Domain 层？
这将是三个层级中最通用的一个。它将 Presentation 层和 Data 层连接起来，并执行应用相关的业务逻辑。
用例
用例是应用逻辑执行程序。正如名称所示，每个功能都可以有其独立的用例。创建更加精细的用例可以被更频繁地复用。
class GetNewsUseCase(private val transformer: FlowableRxTransformer<NewsSourcesEntity>,private val repositories: NewsRepository): BaseFlowableUseCase<NewsSourcesEntity>(transformer){override fun createFlowable(data: Map<String, Any>?): Flowable<NewsSourcesEntity> {return repositories.getNews()}fun getNews(): Flowable<NewsSourcesEntity>{val data = HashMap<String, String>()return single(data)}
}
复制代码此用例返回的是可根据所需观察者进行修改的 Flowable 类型。它有两个参数。其中之一是 transformers 或 ObservableTransformer，它控制执行逻辑的线程和另外的参数 repository，是 Data 层的接口。如果有任何的数据必须传递给 Data 层，则可以使用 HashMap。
Repositories
它指定了由 Data 层实现的用例所需的功能。
什么是 Data 层？
该层级负责提供应用所需的数据。Data 层应该设计任何应用都可以重复使用而无需在其展示逻辑中进行修改的数据。
API 提供远程网络实现。任何网络库都可以集成到这里，如 retrofit、volley 等。同样，DB 提供本地数据库实现。
class NewsRepositoryImpl(private val remote: NewsRemoteImpl,private val cache: NewsCacheImpl) : NewsRepository {override fun getLocalNews(): Flowable<NewsSourcesEntity> {return cache.getNews()}override fun getRemoteNews(): Flowable<NewsSourcesEntity> {return remote.getNews()}override fun getNews(): Flowable<NewsSourcesEntity> {val updateNewsFlowable = remote.getNews()return cache.getNews().mergeWith(updateNewsFlowable.doOnNext{remoteNews -> cache.saveArticles(remoteNews)})}
}
复制代码在 Repository 中，我们有本地、远程或任何类型的数据提供程序的实现，而上面的类 NewsRepositoryImpl.kt 实现了 Domain 层公开的接口。它充当 Data 层的单一访问点。
什么是 Presentation 层？
Presentation 层提供应用的 UI 实现。它不做别的事，只执行没有逻辑的指令。该层内部实现了 MVC、MVP、MVVM、MVI 等架构。所有的连接工作都在本层。
DI 文件夹实现了在应用开始时注入所有的依赖项，如网络相关、View Models、用例等。可以使用 dagger、kodein、koin 或只使用服务定位器模式（service locator pattern）实现 Android 中的 DI。它只取决于应用本身，如对于复杂的应用，DI 可能非常有用。我选择 koin 只是因为它比 dagger 更容易理解和实现。
为什么使用 ViewModels？
根据 Android ViewModel 文档：
以生命周期的方式存储和管理 UI 相关数据。它允许数据在配置更改（例如屏幕旋转）后继续存活。
class NewsViewModel(private val getNewsUseCase: GetNewsUseCase,private val mapper: Mapper<NewsSourcesEntity, NewsSources>) : BaseViewModel() {companion object {private val TAG = "viewmodel"}var mNews = MutableLiveData<Data<NewsSources>>()fun fetchNews() {val disposable = getNewsUseCase.getNews().flatMap { mapper.Flowable(it) }.subscribe({ response ->Log.d(TAG, "On Next Called")mNews.value = Data(responseType = Status.SUCCESSFUL, data = response)}, { error ->Log.d(TAG, "On Error Called")mNews.value = Data(responseType = Status.ERROR, error = Error(error.message))}, {Log.d(TAG, "On Complete Called")})addDisposable(disposable)}fun getNewsLiveData() = mNews
}
复制代码因此，ViewModel 会保留有关配置更改的数据。在 MVP 中，Presenter 使用接口绑定到 view，这会变得难以测试，但在 ViewModel 中，由于架构感知组件（architectural aware components）而没有接口。
Base View Model 使用 CompositeDisposable 来添加所有的 observables 对象，并在生命周期的 @OnCleared 中移除它们。
data class Data<RequestData>(var responseType: Status, var data: RequestData? = null, var error: Error? = null)enum class Status { SUCCESSFUL, ERROR, LOADING }
复制代码数据 wrapper 类作为辅助类用于 LiveData，以便 view 了解数据请求的状态，即它是否已开始、成功或任何有关数据的状态。
如何连接所有的层级？
每个层都有自己特定于该包的 实体类（entities）。Mapper 用于将一个层的实体类转换为另一个层的实体类。我们为每个层设置了不同的实体类，以便该层变得绝对独立，并且只将所需的数据传递给后续的层。
应用流程
本文差不多要结束了，如果我错过了任何内容，请告诉我。让我总结一下：
基础架构定义了应用程序的一致性。诚然，选择什么架构也是基于应用来的，但是为什么不提前选择最合适的架构呢，如可扩展的，强大的，可测试的，这样你就不必在未来面对痛苦。