---
title: "連載介紹 - Clean Architecture in Go"
date: 2025-01-03T00:00:00+08:00
publishDate: 2025-01-03T00:00:00+08:00
lastmod: 2024-10-07T20:05:43+08:00
tags: ["Golang","Clean Architecture","架構","經驗"]
series: "clean-architecture-in-go"
toc: true
permalink: "https://blog.aotoki.me/posts/2025/01/03/clean-architecture-in-go-introduce/"
language: "zh-tw"
---


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

<!--more-->

## 理論到實踐 {#theory-to-practice}

一本書，或者一個知識從了解到理解，最後到能夠應用到底有多大的差距？從 2022 年第一篇「[ 讀 Clean Architecture 學習依賴管理](https://blog.aotoki.me/posts/2022/11/18/learn-dependency-management-by-clean-architecture/)」文章開始，經過兩年的時間才發現我對於 Clean Architecture 的了解並沒有想像中的完整。

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

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

## 模式{#pattern}

Clean Architecture 一書中提供了一個相當不錯的實踐方式，就是提供了一種處理架構的模式（Pattern）來讓我們參考，基於 [SOLID](https://zh.wikipedia.org/zh-tw/SOLID_(%E9%9D%A2%E5%90%91%E5%AF%B9%E8%B1%A1%E8%AE%BE%E8%AE%A1)) 原則開始思考物件之間的關係，透過介面（Interface）進行約定（Contract）來將不同層級的元件區分開來，用來達到軟體的「彈性」也就是讓修改、調整能夠更加的容易。

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

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

## 目標{#goal}

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

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

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