關於 #Golang 的內容

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

google/wire 是一個依賴注入（Dependency Injection）的工具，透過程式碼生成（Code Generate）來幫助我們解決 Golang 中一個物件對另一個物件有依賴關係時，需要事先產生的問題。

在開始這篇之前，也建議閱讀從 wire 學到依賴注入沒有講的事了解一些基本的概念。

mruby 透過編譯器（Compiler，通常是 mrbc）編譯後，會產生 mrb 格式的二進位檔案，這個檔案的格式被稱作 RITE 如果要運行編譯後的 mruby 程式碼，就需要能夠解析並且讀取。

端午節連假利用空檔轉換心情時，把去年重寫後沒有完成的玩具再次拿出來挑戰，剛好在處理一對多的關聯時發現 Domain-Driven Design（領域驅動設計） 中對於 Aggregate（聚合）要作為統一操作其關聯的 Entity（實體）的原因。

有一天在 Facebook 的社團看到有人提到，朋友推薦他多嘗試看看不同的語言，卻不知道該怎麼下手去嘗試。剛好我自己蠻喜歡嘗試各種程式語言，這篇文章會簡單分享該怎麼選擇程式語言。

寫完上篇後就開始員工旅遊、鐵人賽（從讀遊戲原始碼學做連線遊戲）反而一直都沒有時間把下篇寫完，離 COSCUP 都已經過了一個多月自己都忘記還剩什麼沒有寫在文章裡面。

中間在鐵人賽的部分花了一些時間把目前理解到關於 Unlight 的一些基本設計整理出來，後面則是實作。至於近期也已經開始在搭建 HTML5 版本的底層設計，還有 mruby 的整合（因為想提供 Mod 功能到遊戲中）等等東西都在進行中，十一月還要飛日本一趟參加 Ruby World Conference，可以說是完全都閒不下來。

總之，讓我們在來看看 COSCUP 這場演講的後續吧 XD