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

經過一週左右，根據 2024 年底 ihower 的淺談 LLM-based AI Agents 應用開發演講提到的核心概念，用了數百行程式碼完成 Autoflux 這個設計給 Ruby 的 AI Agent 框架，設計過程中反覆修改時思考了一些問題，很值得分享給大家參考。

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

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

印象中「十倍工程師」大約是在我出大學到剛出社會這段期間蠻熱門的一個關鍵字，通常用來指能夠發揮一般工程師十倍生產力的稀有工程師。

假設一天正常工作八小時，我怎麼想都難以理解要怎麼十倍，因為一天只寫了一小時不到的程式。

最近在規劃工作中的一個服務重構，目標是要讓團隊在擴充新的資料源時可以更加快速，以及允許其他團隊貢獻新的資料源。剛好在讀軟體架構原理｜工程方法時裡面介紹的 Microkernel 架構剛好就很適合用來處理這類問題。

近年在台灣使用 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 的應用。