關於 #架構 的內容

在實踐 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 次的聚會，而這次算是表定上的最後一次聚會。在可能是最後一次的聚會，我們先討論了幾個原本沒有要討論的主題。

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

這次在開始討論關於架構的主題之前，我們的倒是讓我們提出一些問題。

剛好在兩次聚會的期間，我的客戶因為一些錯誤的計畫讓 Migration 失敗了，所以我提出了關於在不停機的狀況下做 Migration 的規劃問題。

這次聚會我們先簡單的回顧一下上一次的討論，然後就切換到了下一個主題。基於前一次聚會高併發的討論，我們模擬一個簡單的架構然後開始演進。

昨天是 TGONext 的第一次聚會，在這個活動中我們會向台灣的一些高階主管學習。在開場結束後我們的導師 Ant 讓我們投票選出幾個想在這半年的時間內討論的題目。基本上我們預定討論四個主題，而「高併發」是我們的第一個主題。