關於 #經驗 的內容

基於 Place Order 的實作，我們的專案已經有一個不錯的雛形可以在相當容易擴充的狀況下繼續進行。然而，如果只能建立訂單仍不足以驗證功能完善，因此我們接下來要加入 Lookup Order 來確認是否順利的將資料儲存到記憶體中。

處理完整個流程後，我們可以來做最後的「狀態保存」處理，也就是 Repository（倉庫） 的實作。在這個階段，我們會先使用一個 InMemory 的版本，將狀態暫時性保存在記憶體中，等到我們後續有更完善的規劃後，再回來處理。

Controller 和 UseCase 都有對應的實作後，我們還需要定義在這個系統中負責管理狀態的 Entity（實體）才算是有一個基礎的系統雛形。在這個例子中，我們會需要 Order 和 OrderItem 這兩種實體。

我們已經透過 oapi-codegen 產生了 Controller 的介面定義，然而還沒有任何實作。在 Clean Architecture 中 Controller 要扮演 Adapter（轉接器）的角色，因此我們需要透過 Controller 把使用者的輸入轉換成 UseCase 可以使用的格式。

今年的 Global Game Jam 多樣性成就中，有一個挑戰是「以 Email 進行遊戲」看到的當下就決定要說服（aka 強迫）還不知道會是誰的隊友來挑戰這個題目，因為很適合這個 AI 時代用來進行一些探索性的嘗試。

假設要從零開始開發，相對好的方式是以黑箱的角度思考。也就是我們以「使用者看到的樣子」開始建構系統，並且在過程中逐步的「提煉」將 UseCase、Entity 從系統中提取出來。

這種做法在使用 BDD（Behavior-Driven Development）或者 TDD（Test-Driven Development）也能幫助我們設計出一些初期的測試案例。

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

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

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

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