關於 #經驗 的內容

這一系列會延續以往的做法，以實際的案例來說明。這一次我們會選擇以「訂單服務」作為例子，然而並不是單純的訂單服務，是一個會針對個資加密處理的服務。

在實踐 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 架構剛好就很適合用來處理這類問題。

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

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

這個問題我個人目前還沒有一個邏輯足夠完整的答案，然而最近思考後認為蠻適合拋出來討論。

會回過頭來思考這個問題，也是因為對 Clean Architecture 的使用足夠熟練，要開始準備來深入了解經常一起應用的 Domain-Driven Design，那就一定會遇到這個問題。

最近因為工作的關係稍微回顧了一下 Open Policy Agent 而發現了 AWS 推出的 Cedar Language 更適合在軟體應用上實現類似 AWS IAM 的 Policy（政策）機制，因為是以 Rust 為基底，為了讓 Ruby 可以使用，就決定嘗試使用 Rust 來撰寫 Extension。