真實案例分析分層原則

去過公家機關辦事的人應該都有經驗：等了很久，好不容易輪到自己，櫃台人員卻說「資料不足，請回去補件」。如果能更早被告知缺什麼，半天的時間就不會白白浪費。從這個生活情境切入，剛好能對應到 Clean Architecture（簡潔架構）的分層思路。

本章用一個「申請獎學金」的案例，演練收到需求後該怎麼把元件擺放到 Clean Architecture 的四層之中。

人生如戲#

物件導向程式試圖以「物件之間的互動」模擬真實世界的人事物。要理解抽象的分層概念，最快的方式就是看一個具體案例。

時光倒回幾十年前，還沒有電腦的年代，學生申請獎學金大致會經歷下列流程：

進門時會有一位工讀生上前招呼，了解來意後協助檢查申請單是否填寫完整，避免資料缺漏導致退件。
工讀生引導申請者到「獎學金申請」櫃台坐下排隊，輪到時負責的承辦專員會叫名上前。
專員接過申請單後展開一連串動作：
- 調閱相關資料：包含學籍紀錄、獎學金規章與目前申請狀況，這些資料由檔案管理員從檔案櫃中取出。
- 確認身份與資格：確認申請人為本校學生、符合該獎學金資格、申請日期未逾期等，這些是工讀生無權處理的。
- 填寫官方紀錄：申請人帶來的單據沒有正式效力，專員要在審核通過後撰寫一份正式紀錄並蓋上關防。
- 存檔並回覆：把正式文件交回給檔案管理員歸檔，再開立收據給申請人完成流程。

回到現代，要用程式模擬上述流程，可以對應出下列角色與分層：

工讀生：負責詢問來意、初步檢查文件、引導到合適的專員。對應 ApplyScholarshipController，住在 Adapter 層。
申請書：寫著申請資訊提供給專員參考。對應 ApplicationForm，屬於 UI/Adapter。
「獎學金申請」專員：流程的控制者，向檔案管理員索取資料，依規定審核並填寫正式紀錄。對應 ApplyScholarshipService，屬於 Use Case 層。
檔案管理員：依專員需求調閱或儲存資料。對應 ScholarshipRepository，介於 Use Case 與 Adapter 之間。
「獎學金申請」正式紀錄：載明此申請的官方資訊與核心運算。對應 ScholarshipApplication，是 Entity。
檔案櫃：儲存資料的設備，對應 DB。

這份對照表是「規劃」而非「規定」。後續實作過程中如果發現有更合適的安排，隨時都可以調整與重構。

接下來幾章將從 Interface Adapter 層的 Controller 開始，一層一層往內實作與測試，逐步把這個申請獎學金的功能完成。