分層架構是一個架構設計常見的模式，並且非常適合運用在小型的單體上。他有許多優點，例如：

1. 非常容易就能設計和實作
2. 和人腦的思考方式很吻合
3. 也很容易和人合作共建

當我們談到分層架構，常有一個迷思，為了更容易取代外部依賴，因此我們應該將所有依賴變成一個分層。例如更容易把MySQL換成MongoDB，所以把所有資料庫存取都封裝起來。

事實上，這不是分層架構的目的。我相信我們鮮少需要換掉資料庫、web框架甚至程式語言吧？那麼，到底分層的好處是什麼？

在我們深入討論前，我們先來看一個分層的例子。

上面的圖是一個典型web服務的分層架構。

我們將一個請求的流程分成四個元件，路由層、控制層、服務層和倉儲層。每一個元件都有他的職責，必須處理整個請求流程的部分工作，這樣的精神也稱為單一職責原則(Single-Responsibility Principle)。

在很多文章或書籍中都教導我們，路由層是為了更容易抽換web框架，而倉儲層是為了抽換資料庫。但是，就像我剛說的，我們很少需要換掉那些根深蒂固的元件，這裡的路由層和倉儲層只是為了完成他們的使命。

單一職責原則

既然每個層都有自己的使命，那麼我來介紹一下他們各自的功能吧。

• 路由層是web框架的封裝。為了與框架互動，並且隱藏實作，我們構建路由層把細節隱藏。在路由層，我們需要做的是，定義各種HTTP用的路由，包含URI路徑和HTTP方法，包含GET、POST等。
• 控制層是處理請求的第一線，主要的職責是驗證輸入的請求格式與組裝將要回復的格式。通常錯誤處理也會放在這層，來反應無論是輸入格式錯誤的「400 Bad Request」或者內部邏輯出錯的「500 Internal Server Error」等。
• 服務層是整個商業邏輯的所在地，也是一個產品的核心價值。如果是一個電商網站，那服務層會負責計算推薦、建立訂單、管理金流物流等。同時前端頁面需要呈現的內容，也會在這層進行處理加工。
• 倉儲層是資料庫的上層抽象。為了讓商業邏輯可以獨立於資料庫操作，我們會透過倉儲層來處理資料持久化或各種資料庫查詢事宜，以避免資料操作的邏輯污染商業邏輯。

上面的文字有點抽象，因此我提供一個比較具體的例子：https://github.com/wirelessr/Clean-Architect-in-Golang

這份程式碼拜「尖叫架構」之賜很淺顯易懂，因此我們可以了解一下典型的分層是架構長什麼樣子。

註：尖叫架構指的是光看目錄結構就能知道系統的目的，就像系統在尖叫而得名。

• 路由層是mux這個HTTP框架的封裝。他沒做什麼事，僅僅只有將對應的HTTP請求路由到控制層。
• 控制層定義了API的介面。在AddPost中，他會確認輸入的格式也會組裝要輸出的回覆。
• 服務層有自己的商業邏輯，包含如何拿取儲存的資料、如何產生文件的編號以及管理文章的格式。
• 倉儲層隱藏了所有資料庫的細節，因此可以自由選擇要對接什麼資料庫。但，再一次強調，我們不會隨便換掉已經在使用的資料庫。因此，倉儲層的目的是封裝資料庫的操作，讓服務層不需要關心如何使用firestore。

這樣有什麼好處？

我們只是為了滿足單一職責原則而把一個架構拆成這麼多層嗎？不只是這樣。

這樣的架構有許多好處，讓我解釋一下兩個最重要的優點。

1. 分層讓測試變得更加容易。
2. 如果那些分層都是模組，那我們就可以讓模組發布去耦。

第二個優點很直覺，因此我將重點擺在第一點。

在昨天我們提過，我們可以藉由依賴注入來大幅提高測試的覆蓋率。舉例來說，在我的程式碼範例中，我們可以輕易地建立一個假的資料庫用來控制測試流程。如此一來，就不需要一個真的資料庫並且準備測試資料。

結論

有許多文章都在比較分層架構和微服務架構，但是分層架構並不只是一種架構上的設計模式，更是一種設計原則，用來達成更SOLID的軟體結構。

這篇文章試著用一個實際的例子將分層架構套進微服務架構中，事實證明，分層架構和微服務架構並不是兩個獨立互斥的概念。更重要的是，他們可以彼此互補。