本文同步刊載於個人連載網站

前面幾篇，我一直在整理一件事：

人的工作進到系統裡之後，應該變成哪些功能。

到了 Day 16，我已經會先看一個工作階段最後要完成什麼，再往回整理需要哪些資訊、檔案和操作。

但當這些功能真的開始做進程式裡，我才逐漸看到另一層問題：

這些事情，到底應該由系統裡的哪個部分負責？

我原本理解的分工很粗

開始這個專案之前，我已經知道前端、後端和資料庫這些基本概念。

只是理解很簡單。

大概就是：

• 前端負責畫面和操作。
• 後端負責驗證和處理邏輯。
• 資料庫負責把資料存起來。

所以我平常想事情時，不太會從：

「這個責任應該放在哪一層？」

開始。

我比較常問的是：

「這個功能要怎麼完成？」

需要一個按鈕，就想按下去之後發生什麼。

需要儲存資料，就想最後存去哪裡。

需要處理文件，就去討論程式怎麼讀。

系統分工，是在一個個功能真正被實作之後，才逐漸被我看見。

既然已經有後端，為什麼還要再拆一個服務？

這個感覺最明顯的一次，是做到文件處理。

專案裡需要讀 Excel、處理 Word 和 PDF，後來也有 OCR 需求。

跟 AI 討論方案時，因為 Python 在這類工作上有比較完整的套件生態，所以實作裡出現了一個另外用 Python 寫的文件處理服務。

我當時真正疑惑的是：

既然原本就已經有後端，為什麼不能直接全部寫進去？

在我原本的理解裡，前端以外的邏輯好像都可以叫做後端。

既然都是「後端工作」，放在一起不是最直覺嗎？

繼續討論之後，我才逐漸理解：

後端本身也不是一整塊不能再分的東西。

主要後端負責的是案件流程、權限、業務規則和資料管理。

文件處理服務負責的，則是另一種性質的工作：

讀取 Excel。

解析 Word、PDF。

做 OCR。

產生或轉換文件。

從使用者角度看，這些都只是：

「處理案件裡的一份文件。」

但進到系統裡，它們已經變成不同責任。

使用者看到一個功能，程式裡可能已經拆成好幾部分

這件事讓我第一次比較具體地感覺到：

一個使用者看到的功能，不代表程式裡也應該是一整塊。

使用者仍然只操作同一套產品。

他不需要知道背後是不是多了一個 Python 服務。

主要後端可以在需要時呼叫文件處理服務，再把結果繼續帶回原本的案件流程。

對使用者來說，整件事情還是一個完整功能。

但在工程上，不同性質的責任已經被拆開。

這讓我開始多問一個以前比較少問的問題：

「這件事情真的屬於這裡嗎？」

「存資料」中間也不是只有後端和資料庫

後來，類似的事情又出現在資料存取。

我原本對資料庫的想像很直接：

後端處理完資料，就把它存進資料表。

工程師學長提醒我，後端裡負責業務規則的程式，和真正負責讀寫資料庫的程式，也可以分開。

中間還可以有一層專門處理資料存取，再搭配 ORM 這類工具和資料庫互動。

對有經驗的工程師來說，這可能很基本。

但對當時的我來說，又多看見一個原本被我壓成一句話的地方。

原本我只會說：

「後端把資料存進資料庫。」

後來才知道，這句話裡還可以再拆成：

業務規則怎麼處理。

資料怎麼被讀寫。

資料庫又怎麼被操作。

原本以為直接接在一起的東西，中間也可能有自己的責任分工。

前端和後端之間，也不是「接得起來」就好

前端和後端也是一樣。

一開始我很自然地理解成：

後端回傳資料。

前端拿來顯示。

但功能越來越多，資料格式也越來越複雜之後，問題就不只是：

API 有沒有成功回資料。

前後端還必須對同一份資料有共同理解。

欄位叫什麼？

哪些資料一定會出現？

哪些可能不存在？

格式改動後，另一邊需不需要一起改？

後來我才知道，可以用 API Contract 這類明確約定，把雙方交換的資料定義下來。

對我來說，更重要的不是多學了一個名詞。

而是開始看懂：

前端和後端之間交換資料的地方，本身也是一條需要被維護的邊界。

我還是從「這個功能怎麼做」開始

這些分工都不是我先把整套架構學完，再按照理論設計出來的。

我還是一路從具體功能開始問。

只是 AI 解釋方案、工程師補充做法之後，我原本很粗的「前端、後端、資料庫」慢慢長出了更多細節。

原本我看到的是：

處理文件。

存資料。

把資料給前端。

後來開始看到：

文件處理可以是另一種責任。

業務規則和資料存取可以分開。

前後端之間還有共同約定要維持。

一個功能進到系統裡之後，開始會被拆成不同性質的責任。

而當這些責任真的被拆開之後，下一個問題也跟著出現：

不同部分分開管理了，還要怎麼一起完成同一套產品？