wire 的依賴注入 - Clean Architecture in Go
在實踐 Clean Architecture 的過程中,如果有依賴注入工具的協助會容易很多,初期的效果並不明顯,然而隨著系統成長,要建立的物件逐漸變多後,就會發現能夠自動處理依賴、生成物件是非常重要的,在 Golang 可以使用 google/wire 來協助我們。
在實踐 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。
google/wire 是一個依賴注入(Dependency Injection)的工具,透過程式碼生成(Code Generate)來幫助我們解決 Golang 中一個物件對另一個物件有依賴關係時,需要事先產生的問題。
在開始這篇之前,也建議閱讀從 wire 學到依賴注入沒有講的事了解一些基本的概念。