小編精選 - 技術文章翻譯 · 05月18日

Android Clean Architecture 中的 Use Case 只能有一個方法嗎？

Android Clean Architecture 中 Use Case 只能有一個方法嗎？

很多人第一次接觸 Clean Architecture 時，會產生一個非常典型的誤解：

Use Case 必須只有一個方法。

尤其在 Android + Kotlin 的語境下，這種印象會被進一步強化：

呼叫時：

看起來既優雅又「標準」。久而久之，很多人就默認了：

但實際上，這只是 Android 社群逐漸形成的一種工程風格，並不是 Clean Architecture 的硬性規定。

真正的核心，從來不是「幾個方法」

Clean Architecture 真正關心的是：

業務規則是否獨立
依賴方向是否清晰
模組邊界是否穩定
複雜度是否可控

而不是 Use Case 到底有幾個方法。

所以，正確的理解應該是：

而不是：

登入、提交訂單、重新整理首頁 Feed、發送訊息……這些本質上都是系統行為。Use Case 的職責，是表達這些行為背後的業務邊界。

為什麼「單一 invoke」會流行起來？

雖然不是官方規定，但它確實有明顯的工程優勢。

1. 強制職責單一，防止類別膨脹

當你約定「一個 Use Case 只做一件事」，類別就很難無限膨脹。否則很容易出現這種情況：

kotlin 體驗AI程式碼助手 程式碼解讀複製程式碼class UserUseCase {
    fun login()
    fun logout()
    fun refreshToken()
    fun getProfile()
    fun updateProfile()
    fun deleteAccount()
    // ...越來越多
}

最後 Use Case 退化成第二個 Repository，變成業務垃圾桶。

2. 更符合 Kotlin 的函數式風格

kotlin 體驗AI程式碼助手 程式碼解讀複製程式碼// operator invoke 寫法
loginUseCase(username, password)

// 對比傳統寫法
loginUseCase.execute(username, password)

前者讀起來更像「觸發了一個業務動作」，這也是 Kotlin operator invoke 在這裡非常流行的原因。

3. 更容易組合業務流程

當 Use Case 足夠純粹時，組合它們會非常直觀：

程式碼讀起來就像在看一張業務流程圖，這也是現代 Android 架構裡非常常見的設計思路。

但多個方法並不是錯誤

很多人後來會走向另一個極端：Use Case 必須一個類別一個方法。其實這同樣容易變成形式主義。

來看這個例子：

這並沒有任何問題。因為這三個操作屬於同一個 Session 概念，共享同一批依賴，業務語義高度相關，聚合在一起反而更合理。

如果強行拆開，你可能會得到：

專案稍微大一點，就會出現幾百個 Use Case 檔案，維護體驗未必更好。

Android 真正需要警惕的，不是「幾個方法」

真正的問題是：把 Use Case 寫成 Repository 的轉送層。

很多人會直接把這種寫法定義成反模式，但其實邏輯簡單本身並不是問題。

真正的問題是：整個專案是否已經開始機械式分層。

如果工程裡 200 個 Use Case 全是 repo.xxx() 的轉送，那說明 Use Case 已經失去了業務邊界意義，只是在為了架構而架構。

小邏輯不等於沒價值

這一點很重要，舉個例子：

邏輯不複雜，但它依然有價值。它表達的是「是否登入」這個業務語義，而不是「使用者資料結構」。它把業務語義、UI 關注點和資料模型隔離開了——這本身就已經是一種業務邊界抽象。

真正有價值的 Use Case 是什麼樣的？

成熟的 Use Case，通常會承擔這些職責：業務規則、資料編排、多資料來源協調、快取控制、權限判斷、狀態流轉。

這裡有業務規則、有流程控制、有資料編排，ViewModel 不需要知道任何實作細節。這才是 Use Case 開始真正體現價值的地方。

最後

很多 Android 開發者學習 Clean Architecture 時，容易把架構思想學成類別模板規範，於是開始執著於：

Use Case 必須一個方法
Repository 必須有介面
必須三層、必須 DTO、必須 Mapper……

但 Clean Architecture 真正想解決的，一直都是：複雜度失控、依賴混亂、業務耦合、測試困難。

而不是僅僅「類別到底長什麼樣」。

總結

Use Case 不是一種固定的類別結構，而是一種業務邊界的表達方式。

一個方法可以，多個方法也可以。invoke 可以，execute 也可以。在簡單場景下，甚至不用 Use Case 也完全沒問題（但是商業級專案很少有簡單場景）。

真正重要的，是：你的架構有沒有真的幫助你控制複雜度。

原文出處：https://juejin.cn/post/7640016020847034420