關於 #Clean Architecture 的內容

在實踐 Clean Architecture 的過程中，如果有依賴注入工具的協助會容易很多，初期的效果並不明顯，然而隨著系統成長，要建立的物件逐漸變多後，就會發現能夠自動處理依賴、生成物件是非常重要的，在 Golang 可以使用 google/wire 來協助我們。

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

大約在 2022 年左右，我開始學習到領域驅動開發（Domain-Driven Design，簡稱 DDD）和清楚架構（Clean Architecture）的知識，並且嘗試應用在工作中。然而 DDD 涵蓋的範圍更大，因此先專注在 Clean Architecture 的學習，經過兩年左右的嘗試與實踐，大致上有了一個有體系的實踐方式，再加上 2024 年的 GopherDays 並未接受這個主題，最後選擇以連載形式呈現，因此有這系列的誕生。

近年在台灣使用 Ruby on Rails 的專案逐漸減少，然而在其他國家仍有許多專案使用。這一系列的文章試著從不同的角度看待 Rails 開發的可能性，就是希望能挖掘出更多應用情境。

前面我們主要著重在寫入的處理，如果是單純寫入的處理，我們可以使用 Query 來處理。基本上 Command 和 Query 都可以看作 Use Case（使用案例）的一種，可以根據複雜程度決定是否需要細分，當我們實踐到這個階段，也接近有讀寫分離的系統所呈現的狀態。

最近在帶同事做 Temperature Reading 時拿了一個卡了一段時間的功能出來討論，過程中發現在我們學習軟體開發的經驗中，對於抽象化的訓練大多只停留在「定義一個 Animal 物件」這個層次的理解。

花了一點時間大致上讀了一遍維基百科 Abstraction 的條目，也驗證了我感受到的狀況。

在 Form Object 的階段有提過 Input Object 的概念，與之相對的則是 Output Object 的機制，這兩個物件也正好對應 Clean Architecture 中所提到的 Input Port 和 Output Port 的應用。

當我們將運送模組（取 module Shipments 的方式稱呼）的實體（Entity）確立下來後，就可以來處理倉庫（Repository）也就是我們的資料如何保存的議題。在某些軟體開發的最佳實踐中，會建議推遲資料庫的設計，就是因為一但確定後就難以修改。

依照這次的流程，我們在接近功能完成時才處理，能省去不少前期就確定資料表結構的問題。

到 Use Case 階段我們已經初步跟 Rails 框架做出區隔，建構出屬於我們的 Domain Model（領域模型）然而在 Use Case 中含有許多核心概念的處理並沒有被抽離出來，這些東西就是 Entity（實體）也就是整個領域中要處理的對象（Object）

處理完使用者的輸入後，就可以來著手實際的處理。通常會將這些實作放到 app/ 目錄下，然而當我們要以一個 Domain（領域）來劃分時，使用 lib/ 來放置這些實作可能更加恰當，未來要轉換框架或者搬移，就只需要移動 lib/ 而不會和 Rails 綁定。