Skip to main content

Command Palette

Search for a command to run...

Lesson 1:後端生態系與分層架構思維

Updated
1 min read

後端常見的語言有非常多,包含常見的C#、.NET、Java、Python、Go…等,雖然程式語言眾多,但萬法不離其宗,背後的架構思維解決問題的能力才是工程師的核心價值

關於系列文章採用語言

如果內容包含程式舉例,本文會採用Laravel作為範例語言。

關於PHP

PHP語言本身的底層是透過C語言來進行撰寫的。本身PHP的核心:Zend引擎是完全用 C 語言實現的,它負責將 PHP 程式碼編譯成可執行的中間碼,並處理底層的數據結構和記憶體管理。

PHP的Framework

常見的PHP Framweork:Laravel、CodeIgniter(CI)、CakePHP。但目前的開發者仍以Laravel為大宗。

什麼是Composer

Composer 是 PHP 的「依賴管理工具」 (Dependency Manager) 它的存在是為了服務 整個 PHP 語言,而不僅僅是為了 Laravel。就像 npm 是為了 Node.js,pip 是為了 Python 一樣。

常見開發架構

什麼是MVC架構

MVC,分別對應到:Model、view、controller。
Model 是與資料庫溝通的媒介。View是畫面(Laravel 的命名是 blade)、Controller是控制器(用於調用Model)

在傳統的三層式架構中,就這三個就可以組成一個畫面,但隨著軟體不斷發展,越來越多複雜的邏輯、高複用性的要求、解耦、避免過度肥大...等,三層式架構早已不敷使用,在傳統MVC中,業務邏輯往往被塞進 Controller。但隨著專案變大,Controller 會變得異常肥大且難以維護。這時,我們需要更細緻的分工。

目前最常見的業界結構會是如下:

我們在 Controller 與 Model 之間,加入了 ServiceRepository

  • Repository Pattern (資料庫存取層):

職責: 專注於 DB 查詢邏輯的封裝。

Junior 該懂的觀念: 它的作用是把複雜的 SQL 或 ORM 操作(如 Join, Where 條件組合, Scope)包裝成語意化的方法(例如 findActiveUsers())。

對 Service 來說,Repository 只是負責「執行資料庫查詢」的工具,不涉及其他外部 IO 或邏輯判斷。

  • Service Layer (業務邏輯層):

職責: 專注於 業務流程的調度 。

Junior 該懂的觀念: 它是系統的「大腦」。

決定行為: 判斷現在要先讀 Redis 快取?還是要透過 Repository 去查資料庫?或者是 Call 外部 API?

流程控制: 例如「先去 API 拿匯率,再去 Repository 撈商品價格,最後計算出台幣金額」。這串邏輯是 Service 負責串接的。

他山之石:Django 的 MTV

為了避免陷入單一語言的思維,我們來看看 Python 的 Django。MTV,分別對應到:Model、template、view。我會選擇Django為這個架構的代表框架。

跟上面MVC比較不一樣的是:MTV-View代表的是業務邏輯,而MTV-Template代表的是畫面UI。

名詞不重要,職責分離(Separation of Concerns)才是重點。

從Rookie到Junior,一個後端成長的30堂課

Part 29 of 31

“從 Rookie 到 Junior:一個後端成長的 30 堂課” 是一套專為後端新手所設計的成長型技術系列文章。內容以實務為導向,逐步拆解後端工程的核心能力,包括程式語言基礎、架構思維、框架運作原理、業務邏輯設計、資料庫操作、以及常見的開發模式。 本系列的目標是協助讀者從零散的學習堆疊,建立成體系的後端知識框架。讀者能夠理解各語言背後不變的工程思維與設計原則。這套內容旨在讓學習者從「會寫程式」進入「能理解系統設計」的階段,逐步具備勝任 Junior Backend Engineer 的能力。

Up next

Module 1 資料庫思維與設計

序 歡迎來到後端工程師的練功房。很多人以為後端開發就是寫寫邏輯、把資料塞進資料庫就好。但在工程師眼裡,資料庫的設計往往決定了系統的生死。程式碼寫得再漂亮,如果資料庫設計不良(Schema),系統早晚會因為效能瓶頸(Performance)或資料不一致(Inconsistency)而崩潰。 在 Module 1 中,不會出現基礎的 SQL 語法與 CRUD 指令。我們要從「架構面」切入,先談談如何在程式碼中安放資料邏輯,接著深入「儲存面」的選擇題:何時該用 RDBMS?何時該用 NoSQL? 我們...

More from this blog

Lesson 26 : 系統韌性的守護者-限流、熔斷與背壓的設計模式

當這幾個名詞出現後,代表我們進到了一個高併發/大流量的系統了。在這個章節中,我們一起來看看如何透過一些方式來避免高併發導致我們的系統crash掉。 限流(Rate Limiting) 相信大家對這個名詞並不陌生,限流其實就是字面上的含意,限制流量。 限流的目的是保護「接收方」,確保系統不會因為瞬間的高併發請求而癱瘓。 限流通常發生在 API Gateway 或服務的最前端。它像是一個夜店門口的保全

Mar 26, 20262 min read

Lesson 25: 淺談 單體架構、微服務架構與單/多租戶架構

過去我們討論了 要把程式寫在哪、程式要怎麼拆的題目,接下來我們來看看「如何服務不同客戶」,這些架構反映了軟體開發在擴充性與複雜度之間的權衡。 軟體架構深度解析:從系統拆分到商業規模化 在軟體工程的演進中,架構的選擇往往是在「開發效率」、「系統擴充性」與「營運成本」之間尋求平衡。我們可以從兩個核心維度來觀察這些架構:系統如何運行(單體 vs. 分散式) 以及 如何服務客戶(單租戶 vs. 多租戶)。

Mar 26, 20262 min read

Lesson 24: 資料庫擴展術-讀寫分離、複寫機制與快取一致性挑戰

為什麼要讀寫分離? 大多數的 Web 應用都是 「讀多寫少」(例如:看文的人多,發文的人少,Heavy Read System)。當所有的請求都塞給同一台資料庫時,磁碟 I/O 和連線數會成為瓶頸。 Master (主庫): 負責寫入 (Insert/Update/Delete),確保數據一致性。 Slave (從庫): 負責讀取 (Select),可以有多個從庫來分擔讀取壓力。 為什麼讀

Mar 25, 20262 min read

面試經驗談 2025-2026

從2025年3月開始,我陸陸續續參與了從新創到上市櫃公司的Senior - Tech Lead的相關面試,其中有不乏 尊重面試者、展現高度專業的企業(公司),當然也有遇到幾場面試鬼故事,這篇文章主要分享我對於軟體工程師面試的方向分享,以及部分鬼故事,以此警惕自己不要成為這樣的面試官。 AI的洪流,改變了SWE的生態 LLM的發展確確實實的影響到了軟體工程師的生態。 過去受限於算力與資料規模,深度學

Mar 23, 20262 min read

Lesson 23: 系統的緩衝區-Queue 佇列與非同步處理 (Asynchronous)

佇列 佇列的實作工具非常多,舉凡AWS SQS、RabbitMQ、Kafka…等。 佇列的特性,其實是一個非常強大的系統緩衝區,應用層面非常廣。 什麼是佇列? 佇列可以想像成,在既有流程中外,有另一個”水管”,來連接原有的資料流(或邏輯過程),其中 呼叫方將資料 推(Push)到水管中,接受方(監聽) 從水管中將資料拉(Pull)出處理 為什麼佇列是「強大的緩衝區」? 在同步處理中,系統像是一

Mar 23, 20262 min read

Bennett's Tech Blog | 後端架構、系統設計

32 posts

來自台灣的軟體工程師,相信軟體可以改變世界