目標設定 - Clean Architecture in Go

我們會想導入 Clean Architecture 到專案中，必定是有某些目標想要達成，可能是想要處理長期的計畫，或者是在開發上遇到的痛點。因此在開始之前，我會先分享我對於 Clean Architecture 的理解。

依賴管理

書中有很大一部分都在用「依賴」的情境舉例，因此我在第一次讀完後寫下「讀 Clean Architecture 學習依賴管理」這篇文章，這也是這本書裡面相當重要的一個技巧。

舉例來說，我們希望使用的資料庫可以保持彈性，在未來能夠根據需求替換。那麼，我們就不能將資料庫存取的實作跟商業邏輯耦合在一起，這會讓我們很難針對資料庫的替換修改。

若要達成這個目的，直覺上來說會先把跟資料庫相關的實作抽離成獨立的物件（SRP，單一職責原則）為了要能夠讓這個物件能夠被替換，則會考慮將這個物件以依賴注入的形式提供給商業邏輯（依賴反轉原則）並且定一一個抽象的類別，透過實作抽象類別來達到不同資料庫的支援（里式替換原則）

書中在前半部提到 SOLID 這個原則，很大一部分就是為了後續的修改彈性鋪路，要解決這些物件之間的關係，就需要思考邊界來決定誰依賴誰。

減少衝擊

當我們在修改上獲得更多空間後，對於改變的衝擊就不會那麼巨大，這麼一來我們就能夠更大膽的去修改系統，這對於「軟體」也是一個相當重要的特性。

然而，如果系統並不複雜，實際上即使沒有實踐 Clean Architecture 的衝擊也不大，因此是否要去實踐這些方針，還是要取決於當下維護的系統。大多數情況下，個人練習的專案都不會太過於複雜，因此很少能有系統地去學習這門知識，在工作中實踐跟練習反而更加適合。

例如，從 GDPR 開始各國對個資的保護越來越重視，當公司需要針對個資進行處理的時候，我們當下的設計能透過怎樣的方式修改，在不影響原本計畫的狀況下做出調整，若是沒有設計好架構，對整個開發團隊就會變成非常大的衝擊。

長期維護

最初會投入 Clean Architecture 和 Domain-Driven Design 的學習，就是希望能夠處理大型系統以及長期進行維護，這也是我們透過 Clean Architecture 得到的彈性後，能夠達成的效果之一。

如果有處理過非常老舊的專案，可能遇過某個套件非常老舊也無法更新，但又跟專案的程式碼重度耦合在一起的狀況，這種時候會需要耗費非常大的力氣才能將老舊的套件替換掉。

若是我們依循 Clean Architecture 的思考方式，會發現可以先粗略區分成核心的商業邏輯以及跟這些商業邏輯互動的介面兩大部分，同時這些商業邏輯會透過各種方式來避免對外部依賴，不論是限制參考其他物件，或者是透過依賴反轉用約定（介面）來替代直接參考。

透過這些技巧，會發現這類第三方套件大多數時候只需要加入新套件、實作相同的介面（以 Adapter 的形式）就能夠重新整合到專案中，那麼我們從 Clean Architecture 就獲得了改變的彈性與能夠長期維護的優點。