今天要來整頓一下 To-do List 的專案架構，讓整個開發過程可以比較趨近於實務上的需求！

我覺得這是很重要的一環呢！畢竟學了一個新的語言，就是希望要能夠落地實踐，而且還要知道怎麼應用，那麼，在實務專案中，一般會把專案拆成幾個層次，讓程式模組化、易維護、易測試，一開始就這樣規劃清楚，在未來專案長越大的時候就會很好擴展！

以 To-do List 專案來說，會把架構分成：

TO-DO-LIST/
├─ app/
	├─ main.go                 // 主要入口，只放 Server 和 router
	├─ go.mod
	├─ apihandler/             // 處理 HTTP request
	│   └─ apihandler.go
	├─ model/                  // 定義資料結構
	│   └─ taskModel.go
	├─ service/                // 驗證 CRUD 邏輯
	│   └─ taskService.go
	├─ middleware/             // 放 Middleware function
	│   └─ errorMiddleware.go
	└─ repository/             // 資料存取，CRUD 方法
	    └─ taskRepo.go

看完上面的架構，是不是會有一種霧颯颯的感覺 🫠，我當時也是花了一點時間了解，才看懂為什麼要分成這樣子。
但其實想通了就懂了！！！

因為後端在處理資料的時候，會需要先：
處理前端送來的請求 → 解析送來的資料格式 → 驗證格式是否正確 → 去資料庫拿前端要的資料 → 組裝好之後再回傳給前端

把這一連串的動作拆解之後，就會是像上面的架構，每一個檔案只做一件事，意思就是每一個功能都把它拆開，避免全部都寫在一包檔案裡面，所以只要理解每個檔案的前後連結關係，就可以知道在做什麼了！

接下來，來說明每一層的用意：

1. main.go（主要入口）

只做「 設置 」和「 啟動 」的工作，負責：

• 建立 & 啟動 Gin server（gin.Default()）。
• 放置 router 並綁上 handler，例如：r.GET("/tasks", getTasks)。
• 註冊 middleware（logger、error handler 等）

2. apiHandler/（HTTP request）

接收前端傳來的內容，負責：

• 接收 gin.Context，解析 path、query、headers、body。
• 呼叫 service/ 的函式處理邏輯。
• 回傳 HTTP status / JSON。
• 不會接觸到資料，只做 input / Output。

3. model/（資料結構）

負責：

• 定義資料結構（EX： Task）、輸入型別、簡單的驗證方法（EX： IsValid()）。
• 欄位要使用 JSON tag，錯誤字串要小寫。

4. service/（放邏輯）

放置動作的主要邏輯，負責：

• 應用邏輯實作：資料驗證、錯誤判斷、流程控制（EX：檢查是否存在、再更新）。
• 統一定義錯誤（EX： ErrNotFound），讓 handler 跟 Middleware 只需轉發即可。
• 不依賴前端的資料，所以可單元測試。
• 內容不直接與資料庫連結，所以可以很彈性。

5. repository/（資料存取）

真正處理資料的地方，負責：

• 直接操作資料來源（可先用假資料，真正上線時，再改成資料庫。
• 實作 CRUD 方法（GetAll, GetByID, Create, Update, Delete）。
• 若使用共用記憶體結構要處理 race condition（加上 sync.RWMutex）。
• 回傳 boolean 或 error 表示成功/失敗，service 會根據內容轉換錯誤訊息。

6. middleware/（中間層）

建立共用邏輯的地方，負責：

• EX：request logging、error handling、auth、CORS、recovery 等。
• 統一錯誤訊息並回傳。
• Error middleware 應檢查 c.Errors()，然後決定 HTTP code 與回傳格式。

以上就是大概的內容說明，再來就是要來優化 TO-do List 專案！我們明天見啦～ 👋