The Clean Architecture I

首先 Clean Architecture 是 Uncle Bob 的心血結晶，他同時也是Clean Code 無瑕的程式碼的作者。大神推的很難看懂還有什麼好説的，立馬入坑！

這個架構也被稱之為洋蔥架構 (因為圖片看起來像洋蔥，也有人說會因為寫 樣板代碼 boilerplate code 寫到哭 😭)

以下列出幾項重要特性：

  • 相依性

    內層管理介面，外層管理實作

  • 抽象

    越往內層走越抽象

  • 層與層的互動

    資料的單向流

洋蔥核心 Domain

Domain 由 Entities 和 UseCases 組合而成，透過 Domain 可以讓別人知道你們 App 是關於什麼的，要做什麼的，簡單的就是你的所有業務邏輯！也是 Clean Architecture 最重要的核心。

相依性 Dependency

由上圖左半邊 (右半邊先不看) 我們整理出幾個原則：

  • 外層知道內層
  • 內層不知道外層
  • 外層負責實作 (實現細節)
  • 內層負責介面 (業務邏輯)

良心建議不要跨層依賴，建議只依賴你相鄰的層

抽象原則 Abstraction

越往內層走越抽象，內層負責業務邏輯，外層負責細節實作。 結合上面的相依原則，就可以發現不論內層如何使用抽象的業務邏輯，他不管實作是誰，不需要知道怎麼實作，這樣就很輕易地完成了分離。

上圖拿標準的 3 tier 三層式架構跟 Clean Architecture 做比較，那你會發現三層式架構下，我們業務邏輯理論上不應該知道 DB 的實作，但它知道了。

層與層溝通 Communication between layers

不論你用哪一種架構開發，資料的流動是很重要的，資料的單向流動也是我們所追求的，在洋蔥式架構下是怎麼達到資料的單向流動呢？我們如何在不破壞依賴原則下讓外層資料流到內層，內層資料再流回外層呢？讓我來 seafood 你。

假定我們只有兩層，外層綠色，內層紅色，我們希望資料可以從綠色層（某個 Controller）出發，到達紅色層（經過一些業務邏輯處理），再回到綠色層（某個 Presenter）再做對應變動！

  • 實心箭頭表示組合 has-a
  • 空心箭頭表示繼承 is-a
  • I 和 O 表示輸入和輸出
  • 齒輪表示業務邏輯運算

我們直觀地看出資料是如何流動的：

Controller 使用 has-a 抽象的 use case 接口 (input)，經過邏輯運算產生新的抽象的 use case 接口 (output) 給 is-a Presenter 實作

我們也直觀地看出依賴的方向都是指向 Domain

結論

把握好抽象邏輯業務，依賴原則，資料傳遞的輸入輸出（核心概念也是抽象化解偶）。那這個架構的精神你也已經抓到了有那麼容易嗎？

Reference