目的

前公司在上課的時候超常講到 DI 和 SoC，也就是在 Clean Architecture 中最常用到的技巧，但是感覺沒有好好地刻在我的 DNA 裡，在寫自己的專案的時候還是沒能好好實現 Clean Architecture，於是透過 Uncle Bob 的 Blog 來好好複習一下。

供參 https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html

優點

Clean Architecture 用了 DI 及 SoC 來將各層切得清清楚楚的，為系統帶來了好測試、好維護、好更新的架構，這就是 Clean Architecture 帶來的好處。

經典圖解

Clean Architecture by Uncle Bob

要看懂這張圖要先知道各個圈圈的意思：

  • 藍色-外部服務及工具
    • 框架、資料庫、服務、系統等，從外部獲得的資料源就是最外圈，這層要處理的是如何讓下一層可以看這些外部服務互動。
    • 範例：事先處理好與資料庫的連線，向下一層提供資料庫連線實體，讓下一層可以從資料庫拿取資料。
  • 綠色-介面適配器 (有沒有更好的翻譯…)
    • 從前一層拿到可以和外部互動的實體後，在這層處理好應該怎麼拿到資料，抽象成規範好的資料格式後提供給下一層使用，透過這層不論是用 SQL 或是 NoSQL 甚至是 gRPC 都不會影響下一層如何使用數據。
    • 範例：將 SQL 寫在這層，讓下一層只需呼叫我們指定的方法與參數就可以得到他們想到的東西，如果為了其他考量換了其他資料庫或是資料來源，就只有這層需要變動。
  • 紅色-使用案例
    • 通常透過函式定義如何操作實體(下一層)或是實體之間該如何互動，也就是商業邏輯。
    • 範例：”建立訂單”這個動作，透過操作用戶及產品產生出新的一張訂單，就是這層在做的事情。
  • 黃色-實體
    • 透過建立各個可以表達業務規則的實體或是函式，不會受到外部性影響。
    • 範例：”產品”作為業務規則的核心，從一開始定義好了會有哪些資訊，基本上也不應該不會有太大的變動。

注意事項

解釋完上面的經典圈圈之後，來講一下注意事項。

  • 各層專注處理好自己要做的事，內層不會使用到外層的任何事物，這樣才能更好地把各層切開，也就是關注點分離。
  • 不依賴任何框架、資料庫或是外部服務，永遠忠於自己的商業邏輯去規劃你的系統，這些外部屬性都是基於需求被放進系統中，隨時可以被淘汰替換。
  • 寫好的系統應該要具有很好的可測試性，像是能夠很好的替換別層元件進行測試，如果做不到的話就應該重新檢視是不是哪裡沒有切好。
  • 不只四層圈圈，這四層只是用來說明基本概念，如果要應用於更複雜的系統或是商業邏輯，就根據需求切出更多的層次。

總結

Clean Architecture 提供了方法論，但是要套用到工作流程還是要多實踐幾次，才能夠融會貫通，而不是一知半解。