初學者入門：什麼是「服務」？從軟體設計談起

更新日期： 2025 年 3 月 27 日

你是否曾在學寫後端時，聽過「這是個 Service 層」、「請呼叫某個 service」、「把邏輯抽成 service 比較好管理」這類的說法？

對於剛入門軟體設計的你來說，「Service（服務）」這個詞可能讓你有點霧煞煞：它到底是個函數、一段功能、還是一個檔案？

別擔心，這篇文章會帶你從生活例子開始，一步步拆解「服務」這個抽象名詞，並用簡單的語言告訴你：它是什麼、為什麼需要它、又該怎麼使用它。

什麼是「服務」？

「服務」不是只有客服、外送或叫車

當你聽到「服務」這個詞，腦中可能會立刻浮現餐廳的桌邊服務、Uber 的叫車服務，或者線上客服的即時回應。

這些情境有一個共通點：它們都是「幫你做某件事」的系統或人員。

也就是說，服務的本質是：對外提供一項特定功能，幫助使用者完成某個任務。

在軟體設計中，「服務」的意涵和這個生活概念非常接近。當我們在程式碼裡提到一個「服務」，我們指的是：

一段封裝好的邏輯，用來處理一個特定的任務或流程，可以被其他地方重複呼叫，不用每次都重新實作。

舉例來說，如果你要開發一個線上商店，使用者點擊「下訂單」這個按鈕時，你的系統背後可能會執行以下流程：

1. 檢查商品庫存
2. 計算訂單金額
3. 建立訂單記錄
4. 發送通知給物流系統

這整個流程就可以包裝成一個「OrderService」，讓你在任何需要建立訂單的地方，都可以重複使用這段邏輯。

軟體中的「服務」

初學者常見疑問：服務到底是什麼？

學習後端或系統設計時，很多人會困惑：「服務（Service）是不是就是一個函數？還是某種功能？」

這個問題很正常，因為在程式碼裡，Service 通常看起來就是一段會執行一連串邏輯的東西，有時也的確會讓程式完成一個功能。

但要搞清楚服務的定位，我們先來分清楚這三個概念：函數、服務、功能。

函數（Function）：小單位的動作

函數是最基本的單位，通常用來執行一件明確的小事。像是：

• 把價格加上稅
• 把資料轉成 JSON 格式
• 檢查密碼長度是否足夠

每個函數只關心一個很小的細節，越單一越好，這樣才能重複使用、容易測試。

功能（Feature）：使用者會看到的結果

功能是面對使用者的產品需求，例如：

• 使用者登入
• 新增商品到購物車
• 完成一筆訂單

這些都是使用者角度的「完成一件事」，但你不用看到細節，只在乎「我按下去，事情有發生」。

服務（Service）：負責把小動作組合起來，完成一段完整流程

服務是站在程式的角度來看功能。

它不直接面對使用者，而是負責把多個函數組起來，實作一個完整的邏輯流程，通常這段邏輯會對應到某個「功能」的背後。

以「下訂單」為例，對使用者來說只是按個按鈕，但在系統內部，這背後可能包含：

1. 驗證用戶身分
2. 檢查商品庫存
3. 計算總價與折扣
4. 建立訂單記錄
5. 扣除庫存、發送通知、更新用戶積分……

這麼多步驟不可能寫在 Controller 裡，也不適合拆成一堆零散函數散在各處。這時就會建立一個 OrderService，專門負責處理與「訂單」有關的邏輯。

更實用的比喻：做一杯咖啡

我們用做咖啡來比喻，會更清楚：

• 函數（Function） 就像是「磨咖啡豆」、「加熱水」、「倒牛奶」這些單一動作。
• 服務（Service） 是把這些步驟串起來，完成一整個「沖一杯拿鐵」的流程。
• 功能（Feature） 是使用者在咖啡機上按下「拿鐵」按鈕——他不管你怎麼做，只在乎最後有咖啡喝。

你可以這樣記：

• 🧱 函數 = 基本零件
• 🏗️ 服務 = 組裝流程
• 🛒 功能 = 使用者看到的成品

服務的價值在於：把程式的「思考流程」清楚組織起來，讓程式好讀、好維護、好重用。

為什麼要用「服務」？

在剛開始寫後端的時候，很多人會習慣把所有邏輯直接寫在 Controller 裡。

看起來很直覺、很快、功能也都跑得動——但等專案一變大，功能一複雜，你就會發現整份程式碼像義大利麵一樣纏在一起，超難維護。

這時候你會後悔沒有早點學會「服務」的用法。

以下這三個原因，說明為什麼「Service」在軟體設計中這麼重要。

分離關注點（Separation of Concerns）

把每一層的責任講清楚，程式才不會亂成一團

在良好的系統架構裡，我們通常會把邏輯拆成三層：

• Controller：處理「誰來了」、「要什麼」，像是收請求、檢查參數、決定回應格式。
• Model：負責「資料怎麼來」、「存到哪」，主要處理跟資料庫的互動。
• Service：介於中間，負責「事情怎麼做」，也就是商業邏輯或流程控制。

舉個例子來看：

flowchart LR
    User([使用者]) -->|按下「下訂單」| Controller[Controller 收到請求]
    Controller -->|呼叫| OrderService[OrderService]
    
    subgraph OrderProcessing[訂單處理流程]
        Step1[檢查庫存] --> Step2[計算價格]
        Step2 --> Step3[建立訂單]
        Step3 --> Step4[更新用戶積分]
    end
    
    OrderService --> OrderProcessing
    OrderProcessing --> Response[回傳成功訊息]

這種分工方式的好處是什麼？

你以後要改「怎麼下訂單」的流程時，只要動 OrderService 就好，Controller 跟資料庫那邊完全不用動。

而如果你把所有邏輯都寫在 Controller 裡，那這支檔案可能會長成 300 行、500 行，別人要維護時根本無從下手（甚至你自己一週後也會忘記寫了什麼）。

提高可維護性與重用性

重複的程式碼是地雷，改邏輯要改三次更是災難

把邏輯抽出成 Service 之後，最大的好處之一就是：不用一直寫重複的東西，而且一個改動不會牽動整個系統崩潰。

✅ 範例一：減少重複程式碼

假設你在三個地方都需要「驗證訂單是否合法」，你可以在 OrderService 裡寫一次 validateOrder()，然後到處重用。

不用每次都貼一份一樣的驗證邏輯。

✅ 範例二：邏輯集中管理，未來好修改

假設公司現在活動改變，結帳要改成「滿千送百」，你只要改 OrderService 裡處理價格的那段邏輯就好。

Controller 不動、前端不動，整個系統就自動適應新規則。

✅ 範例三：不同功能可以共用同一個 Service

可能你有三個地方會建立訂單（直接購買、從購物車、從活動頁面），這三種都可以共用 OrderService.createOrder()，不用寫三次。

方便測試與除錯

邏輯分開寫，才好測試一塊一塊的功能

如果你把業務邏輯都寫在 Controller 裡，那測試起來會很痛苦——你必須要模擬整個 HTTP 請求流程、塞參數、建資料庫、跑一大堆 setup。

但如果你把核心邏輯都放在 Service，那就可以針對單一函式、單一流程做單元測試（Unit Test）。

✅ 範例：針對服務函式做乾淨測試

你可以直接測：

const result = await OrderService.calculateTotalPrice(cartItems, userCoupons);
expect(result.total).toBe(1599);

這樣的測試既快速又準確，也不需要模擬整個請求、資料庫，只測一段邏輯而已。

更棒的是，當測試失敗時，你更容易知道問題出在哪一層，快速定位錯誤。

小結：你不把邏輯拆進 Service，將來一定後悔

• 少用 Service 的程式碼，會又臭又長、難以維護。
• 重複寫邏輯，不只浪費時間，更容易出 Bug。
• 測試變得麻煩，Debug 變得更痛苦。

而Service 的存在就是為了解決這些痛點，幫你把邏輯集中、模組化、結構化。它不只是好用，而是寫好一個可長可久系統的基礎。

如何撰寫一個「服務」？

建立一個服務，其實就是把「一件事情該怎麼做」的邏輯整理好，然後包裝成一個獨立的模組，讓程式其他地方可以輕鬆呼叫。整個流程大致可以分成兩步：

建議的專案結構

📁 services
│  └── OrderService.js   ← 專門處理與訂單相關的邏輯
📁 routes
│  └── orderRoutes.js     ← 處理 API 請求，並轉交給 Service

Step 1：先建立一個服務類別，把商業邏輯包起來

這一步我們要做的，是「整理好一整段流程」，並拆成有條理的程式碼。

做法如下：

📌 一開始先建立一個服務的檔案

通常會放在 services 這個資料夾，例如：

/services/OrderService.js

📌 然後開始寫這個服務類別的骨架

class OrderService {
  async createOrder(userId, items) {
    // 這是主要流程的入口，負責統整整個訂單流程
  }

  // 下面這些是被主要流程呼叫的小功能
  calculateTotal(items) { ... }
  async saveOrderToDB(...) { ... }
  async sendNotification(...) { ... }
}

這裡有幾個設計重點：

• 最上面那個函數（例如 createOrder()）是「對外的主入口」，用來整合整個流程。
• 底下的小函式是支援的功能，像是「計算價格」、「儲存訂單」、「發送通知」等，每一個都只負責做一件事。
• 最後記得用 module.exports = new OrderService() 匯出整個服務，這樣別的地方才能調用。

✅ 實作範例

// services/OrderService.js

class OrderService {
  async createOrder(userId, items) {
    if (!userId || !items || items.length === 0) {
      throw new Error('資料不完整');
    }

    const total = this.calculateTotal(items);
    const order = await this.saveOrderToDB(userId, items, total);
    await this.sendNotification(userId, order);

    return {
      success: true,
      message: '訂單建立成功',
      orderId: order.id,
    };
  }

  calculateTotal(items) {
    return items.reduce((sum, item) => sum + item.price * item.quantity, 0);
  }

  async saveOrderToDB(userId, items, total) {
    return {
      id: 'order_123',
      userId,
      items,
      total,
    };
  }

  async sendNotification(userId, order) {
    console.log(`通知用戶 ${userId}，訂單 ${order.id} 已建立`);
  }
}

module.exports = new OrderService();

這樣你就把「建立訂單」這件事情變成了一個可以重複使用的服務，裡面流程清楚，每段邏輯都有自己的位置。

Step 2：建立一個 API 路由來呼叫這個服務

服務本身不會直接處理 HTTP 請求，這部分交給 Controller（或 route handler）來做。

你可以在 /routes/orderRoutes.js 裡面寫一個 API 端點，當使用者送出「建立訂單」的請求時，轉交給我們剛剛寫好的 OrderService 處理。

✅ 實作範例

// routes/orderRoutes.js

const express = require('express');
const router = express.Router();
const OrderService = require('../services/OrderService');

router.post('/order', async (req, res) => {
  const { userId, items } = req.body;

  try {
    const result = await OrderService.createOrder(userId, items);
    res.status(200).json(result);
  } catch (err) {
    res.status(400).json({
      success: false,
      message: err.message,
    });
  }
});

module.exports = router;

📌 這裡的重點：

• API 路由只負責「接資料 → 丟給服務 → 回應結果」，邏輯越簡單越好。
• 真正的邏輯細節（驗證、計算、儲存）全都由 OrderService 處理，Controller 根本不需要知道流程細節。
• 未來你只要修改服務內的邏輯，這個 API 就會自動套用最新邏輯，不用重寫請求處理的部分。

這樣的分層設計帶來什麼好處？

✅ 小結

• 建立一個 Service 就是把一整段業務流程封裝起來，放在一個獨立模組裡。
• 使用 class 或物件方式撰寫，可以清楚地管理與某個主題（如訂單、用戶、通知）相關的邏輯。
• Controller 僅負責「接收資料、調用服務、回應結果」，讓每一層責任明確分工。

這是建立乾淨、可維護後端架構的重要一步，也是從「寫得動」邁向「寫得好」的分水嶺。

Service、API 和微服務（Microservice）是什麼關係？

當你開始把商業邏輯拆成服務（Service）後，下一個常見的問題是：

「那 Service 是不是就是 API？」
「跟微服務（Microservice）有什麼關係？」
「我現在在寫的 Service，以後要不要變成一個獨立系統？」

這些問題很常見，也很值得釐清。以下我們就從實務角度，幫你梳理三者的關係。

API 和 Service 的關係是什麼？

在實作一個 Web 系統時，API 與 Service 是兩個分工明確的角色，但許多初學者常會搞混，尤其在剛接觸後端開發的時候，會問：

「我寫了一個 Service，不就是一個 API 嗎？」
「API 處理完回傳就好，為什麼還要多一層 Service？」

讓我們用清楚的邏輯與比喻，一次說明白。

✅ 概念釐清：

• API 是系統對外開放的「入口」，通常是一個 HTTP 路由，讓前端、App、第三方服務可以送資料進來請你做事。
• Service 是系統內部處理「這件事怎麼做」的邏輯模組，它不直接跟外界溝通，只負責處理你交代給它的工作。

換句話說：

API 負責「接任務」，Service 負責「做任務」。

🍜 更貼切的比喻：系統就像一間餐廳

讓我們用一間有內用服務的餐廳來類比整個系統的運作流程。

🧾 對照流程一覽：

1. 顧客走進餐廳、點了一份咖哩飯（使用者發出 API 請求：POST /order）
2. 服務生接到點餐內容（Controller 接收到請求資料）
3. 服務生把訂單交給廚房（Controller 呼叫 OrderService）
4. 廚房照著指示下廚煮菜（OrderService 處理商業邏輯：驗證、儲存、通知）
5. 餐點完成，服務生端上桌（Controller 回傳處理結果給前端）

✅ 為什麼要有 Service？

因為你不可能讓服務生（Controller）自己進廚房煮飯，還要跑去接客、收錢、送單。這樣會讓整個流程又亂又難維護。

同樣的，在程式裡，如果你把所有邏輯都塞在 Controller 裡，會變成「什麼都做的萬能函式」，未來一旦邏輯複雜起來，根本維護不了。

所以我們用 Service 把「怎麼做一件事」的細節封裝起來，讓 Controller 只負責傳資料、拿結果、回應使用者。

🧠 小結：誰做什麼？

🧩 延伸一下：不是所有 Service 都要開 API

你在系統裡可能會建立很多不同用途的 Service，例如：

• OrderService：下訂單流程
• CouponService：處理折扣邏輯
• EmailService：發送通知信件

但並不是每個 Service 都需要對外提供 API，很多 Service 是給內部用的工具模組，只讓其他 Service 或 Controller 呼叫，不需要單獨開一條 HTTP 路徑給外部使用。

微服務（Microservice）到底是什麼？

當你開始熟悉 Service 的概念後，接下來你可能會遇到另一個常出現的詞：「微服務（Microservice）」。

雖然它的名字裡也有「Service」，但它不是一種程式寫法，而是一種系統架構設計的方式。

簡單來說：

微服務不是寫很多個 Service，而是把整個應用程式拆成多個獨立的、小型的應用服務（應用程式本身）來運作。

✅ 微服務 vs 一般的 Service：差在哪？

🔍 為什麼要用微服務架構？

當你的系統越做越大，原本寫在同一個專案裡的 Service 數量變多，互相之間依賴越來越強，這時候就會出現一些問題：

• 維護困難：一個小小的功能更新，可能會影響整個系統，導致其他功能也壞掉。
• 部署風險高：每次上線都要重新部署整個系統，哪怕只改了一個小地方。
• 開發效率降低：多個團隊共用同一份程式碼，常常會踩到彼此的修改。
• 擴充困難：某些模組（像訂單、商品）很常被使用，但沒辦法獨立調整效能或配置。

為了解決這些問題，微服務架構的想法就出現了：

把系統拆成「多個小應用」，每個微服務只負責一件事，讓它可以獨立運作、獨立開發、獨立部署，互不影響。

📦 實際案例：電商系統怎麼拆成微服務？

假設你在開發一個電商平台，一開始所有功能可能都寫在同一個後端應用中，但當流量增加、功能變複雜，你會開始考慮把它拆分成以下微服務：

每個服務都是獨立的應用程式，可能：

• 使用不同的程式語言（如 Order Service 用 Node.js，User Service 用 Go）
• 有各自的資料庫（User 用 PostgreSQL，Order 用 MongoDB）
• 部署在不同的伺服器、容器（如 Docker）甚至雲平台上

🔗 微服務之間怎麼互相溝通？

既然是拆開的服務，那它們彼此之間怎麼交流資料、協作處理一個完整的任務呢？這就會用到以下幾種方式：

1. REST API 呼叫

最直覺的方式。像是 Order Service 在建立訂單時，會去呼叫 Product Service 的 /products/:id API 來確認庫存。

2. gRPC 或 GraphQL

在微服務之間需要高效能、強類型的資料傳遞時，會使用 gRPC 來取代傳統的 HTTP。

3. 事件驅動（Event-Driven Architecture）

使用像 Kafka、RabbitMQ、SQS 等佇列系統，讓服務之間用「發送事件」的方式來互相通知，實現解耦合的溝通。

例如：

• Order Service 建立訂單後，發出一個 order.created 事件
• Notification Service 收到這個事件後，自動發 email 給用戶
• Inventory Service 收到事件後自動扣庫存

🧠 小提醒：不是所有專案都需要微服務

微服務聽起來很厲害，但也不是萬靈丹。

它其實是為了解決「大型系統的維護痛點」而設計的，如果你的系統還不夠大、團隊還不夠多，硬拆微服務只會讓事情變得更麻煩。

微服務的缺點也不少：

• 部署變複雜
• 測試難度提高
• 需要設計跨服務的認證、追蹤、錯誤處理
• 運維成本上升

所以通常建議的做法是：

從單體應用（Monolith）開始，先用乾淨的模組化（Service 分層）寫法，等系統變大後，再視情況慢慢切成微服務。

所以簡單整理三者的層次與關係：

💡 補充：什麼時候需要微服務？

初學者一開始不需要刻意寫「微服務」，大部分中小型專案用單一系統 + 模組化 Service 架構就足夠。
等到你遇到以下狀況，就可能會考慮走微服務：

• 不同團隊負責不同系統區塊，需要分開部署與開發
• 某些模組需要獨立擴充流量或效能
• 某些服務的穩定性、法規、安全性要隔離管理

小結：服務是軟體設計的靈魂之一

對初學者來說，理解「Service」這個概念是邁向乾淨架構、可維護程式碼的第一步。

記住以下幾點：

✅ 服務 ≠ 函數，但服務會用到函數
✅ 服務 ≠ 功能，但服務實作了功能的邏輯
✅ 服務 = 一種封裝業務邏輯的結構，幫助程式模組化、可維護、可測試

未來當你開始重構專案、讀懂別人的程式碼、甚至參與團隊合作時，這個基礎概念會幫你少走很多冤枉路。