關於 #架構 的內容

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

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

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

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

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

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

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

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

有段時間沒有寫 Domain-Driven Design（以下簡稱 DDD）的主題，最近剛好跟一些朋友討論以及做了不少實驗，覺得可以針對這些題目再一次討論在 Ruby on Rails 中導入會遇到的問題。

教召一直是讀書的好時機，因此我利用五天的時間把 Clean Architecture 讀完。讓我覺得意外的是，以往我聽到在討論一些主題時會提到這本書的內容，其實大多跟這本書想傳達的資訊不太一致，除此之外我認為有很多值得討論的地方也沒有被大家討論。

在 TGONext 期間我們基本上有 4 ~ 5 次的聚會，而這次算是表定上的最後一次聚會。在可能是最後一次的聚會，我們先討論了幾個原本沒有要討論的主題。

這次聚會中，我們會討論關於日誌追蹤跟如何處理技術債。