Interface 不是有開就好：從一個 PR 來看抽象化的重要性

raiven.kao@gmail.com (Raiven Kao) — Sat, 04 Oct 2025 00:00:00 +0000

前言

最近團隊正在開發一個新產品，其中一個核心功能需要 client 與 server 之間進行即時、雙向的溝通。經過一番技術評估，我們決定採用 WebSocket 來實現這個需求。

身為一個良好習慣的開發團隊，我們在開發初期就導入了依賴注入（Dependency Injection），希望透過界面（Interface）來解耦商業邏輯與具體的實作，這樣不僅能提高程式碼的可測試性，未來在更換底層實作時也能更加輕鬆。

一切聽起來都很美好，直到我在一次 Code Review 中，看到了一段熟悉的程式碼。

一個 PR 的故事

在我們的 Domain Layer，也就是處理核心商業邏輯的地方，我看到同事定義了下面這個 interface：

// package/to/domain/service.go

// WebSocketService defines the interface for websocket communication.
type WebSocketService interface {
    // StartAndLinsten starts the service and listens for incoming messages.
    StartAndLinsten(ctx context.Context) error

    // Send sends a message to the client.
    Send(ctx context.Context, message any) error

    // ... other methods
}

第一眼看過去，好像沒什麼大問題。有名稱、有方法、也確實是個 interface。然而，當我細看 WebSocketService 這個命名時，總覺得哪裡怪怪的。

於是我在 PR 上留下了這樣的 comment：

這個界面主要是抽象化 client 與 server 間的互動，不應該侷限於 WebSocket 這個 Protocol。假如我們未來要換成使用 socket.io 或是 gRPC stream，是不是連 domain 層的 interface 也要跟著改動？

Architecture on omegaatt

Interface 不是有開就好：從一個 PR 來看抽象化的重要性

前言

一個 PR 的故事