Google-Clean 框架理解

Clean Architecture

一、Why Architecture 是重要的

所有架構都有一個共同的目標-管理應用程序的複雜性。在較小的項目中，您可能不必擔心它，但是在較大的項目中，它變成了救生員。 Clean Architecture 如何解決這個問題？

What

先上一個圖：

簡單的說明一下這個圖：

Enterprise Business Rules：業務對象

Application Business Rules：用於處理我們的業務對象，業務邏輯所在，也稱爲Interactor

Interface Adapters： 接口轉換，拿到我們需要的數據，表現層（Presenters）和控制層（Controllers）就在這一層

Frameworks and Drivers: 這裏是所有具體的實現了：比如：UI，工具類，基礎框架等等。

圓圈代表您應用中軟件的不同級別。有兩件事要注意：

1.中心圓是最抽象的，而外部圓是最具體的。這稱爲抽象原理。抽象原理指定內部圈子應包含業務邏輯，外部圈子應包含實現細節。

2.乾淨架構的另一個原則是依賴規則。該規則指定每個圓只能依賴於最近的向內圓-這就是使體系結構起作用的原因。

外圈代表特定於平臺的具體機制，例如網絡和數據庫訪問。向內移動，每個圓圈都更加抽象和更高層次。中心圈是最抽象的，包含業務邏輯，它不依賴您使用的平臺或框架。

在構建應用程序代碼時使用體系結構的其他好處包括：部分代碼解耦，更易於重用和測試。有一種瘋狂的方法。當其他人使用您的代碼時，他們可以學習該應用程序的體系結構並會更好地理解它。

Clean Architecture 層級

一般的分類是五層：

• Presentation: 與UI交互的層。
• Use cases: 有時稱爲交互器。定義用戶可以觸發的動作。
• Domain: 包含應用程序的業務邏輯。
• Data: 所有數據源的抽象定義。
• Framework: 實現與Android SDK的交互，併爲數據層提供具體的實現。

常見的MVP的相關的Project 結構

how

這裏已Google的 MVVM架構 architecture-samples-usecases 爲例子

比基本的MVVM架構其中添加了一層新的Domain Layer層。其包裝都是通過一個個UseCase來完成V層和M層的交互的。

目錄結構：

我們看看基礎的文件目錄的不同，其添加了一個domain的一個目錄，裏面有多個usecase的類，用於對Task的操作。

addedittask：這個目錄可以看成是Presentation層。用於UI相關的交互。

data：這個目錄可以看成Model層。Task類是保存的基本的任務信息類，都是以Task基本對象來傳遞任務。

其中的TasksDataSource、TasksRepository兩個接口很重要，前面說到的內層不能持有外側，那麼這個怎麼交互呢就靠這個接口。各個UseCase中間的交互調用接口。

而local中則是最外側的實現接口的部分。

domain：這裏封裝了各個業務邏輯的UseCase。可能這個UseCase的概念需要理一理，舉例說上面的一個刪除任務的業務邏輯就封裝成一個UseCase。 Domain層的大部分業務邏輯都是在Use Case中實現的。這裏是一個純java模塊，不包含任何的Android依賴

一個刪除業務的時序圖：

基本分析一下UseCase ：

class DeleteTaskUseCase(
    private val tasksRepository: TasksRepository
) {
            suspend operator fun invoke(taskId: String) {

        wrapEspressoIdlingResource {
            return tasksRepository.deleteTask(taskId)
        }
    }
}

這裏再看一下ViewModel中的調用關係，這裏調用之後得到返回值，再把事件給相關的LiveData.在TaskDetailFragment中監聽相關的事件變化，從而完成整個的事件的處理。

    fun deleteTask() = viewModelScope.launch {
        taskId?.let {
            deleteTaskUseCase(it)
            _deleteTaskEvent.value = Event(Unit)
        }
    }

到這裏流程已經講了一遍，如果不清楚流程可以研究一下，一開始的時序圖。

Why

• Easy to maintain 易於維護
• Easy to test 易於測試
• Very cohesive 高內聚
• Decoupled 解耦

高內聚和低耦合側重於理解了。但是易於維護，這樣的結構已經能說明了，易於測試也好理解，各個模塊獨立，來看看這：

• 展示層 (Presentation Layer) : 使用android instrumentation和espresso進行集成和功能測試
• 領域層 (Domain Layer) :使用JUnit和Mockito進行單元測試
• 數據層 (Data Layer) :使用Robolectric（因爲依賴於Android SDK中的類）進行集成測試和單元測試