連載介紹 - Clean Architecture in Go

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

理論到實踐

一本書，或者一個知識從了解到理解，最後到能夠應用到底有多大的差距？從 2022 年第一篇「 讀 Clean Architecture 學習依賴管理」文章開始，經過兩年的時間才發現我對於 Clean Architecture 的了解並沒有想像中的完整。

除此之外，涉及到架構層面的問題，大多數時候不是一種「公式解」的方式可以解決的，更多是綜合的考量和取捨所下的判斷，因此書中不會給出完整的案例，也無法粗暴地套用到任何情境上，只能依靠讀者的理解慢慢摸索。

我在 2023 年 RubyConfTW 演講中選擇用「指引（Guide）」的方式描述架構也是這個原因，要以架構層級思考問題，我們需要關注的不是設計細節，而是整體的結構是否能夠處於一個平衡，進而取得最接近理想的成果。

模式

Clean Architecture 一書中提供了一個相當不錯的實踐方式，就是提供了一種處理架構的模式（Pattern）來讓我們參考，基於 SOLID 原則開始思考物件之間的關係，透過介面（Interface）進行約定（Contract）來將不同層級的元件區分開來，用來達到軟體的「彈性」也就是讓修改、調整能夠更加的容易。

正因為這種思考的方式能夠幫助我們區分出抽象程度（如：商業邏輯、使用者介面）的差異，以及每個物件之間相互依賴對於改變的影響，才得以讓軟體的架構變得清晰，使我們可以更清楚的了解到每個物件具備怎樣的職責、可以被哪種物件替換、需要依賴哪些物件才能運作等等資訊。

在這幾年工作、個人專案的實踐中，也開始感受到架構與模式的影響。以「產生物件」的情境來說，會根據我們在架構設計的目標不同，會採用 Factory 或者 Builder 來生成某個物件，若是沒有考慮架構，那麼可能就只是剛好在重構中注意到這樣的特性，然而在架構的指引之下，就很容易能注意到哪一種設計模式更加適合。

目標

這一系列的目標是以實際的功能開發作為案例，總結我過去兩年多在 Clean Architecture 的學習跟理解，以及實際上在工作中應用後得到的實踐方式。

如同一開始所提到的架構層級問題，這系列不會以解答各種情境的角度來撰寫，而是以大多數情況都能適用的作法，也是 Clean Architecture 書中所採用的案例，擁有四層的架構規劃，分別是處理底層的 Framework、與商業邏輯對接的 Controller、Presenter、每個領域（Domain）能做的行為 Use Case 以及作為核心邏輯的 Entity 來舉例。

透過這樣的案例，可以看到我們是如何讓 HTTP API 的實作，能夠擴充支援 gRPC 而不會有巨大的改動，以及四層架構中，每一層之間的邊界是怎樣形成的。