Day7_架構想好了，那流程怎麼操作呢？用流程圖說明一下

前言

上一篇 Day6_我理想中的網頁，應該要是什麼樣子？，我們從 User Story 整理出登入、專案、Task 清單與詳情頁。畫面有了，接著要問的是：使用者按下按鈕後，系統要怎麼走？

這一篇會把 Day6 畫面裡的操作展開成流程圖。除了順利完成的路徑，我也會把欄位驗證、權限不足、資料衝突和外部服務失敗畫進來。這些分支若沒先想清楚，實作時很容易只剩下可以正常操作的版本。

畫每一張流程圖時，我先固定三個原則：

1. 前端是否顯示按鈕不能取代後端授權，所有寫入操作都要由後端再次檢查權限。
2. 表單送出期間要避免重複提交，成功與失敗都要提供清楚的畫面訊息。
3. 資料頁面應考慮 Loading、Empty、Validation、Forbidden 與 Error 狀態。

註冊、Email 驗證與登入

註冊與 Email 驗證

登入

登入失敗訊息不應透露帳號是否存在。驗證完成前或已停用的帳號都不能登入；驗證連結也要設定有效期限，過期後由使用者重新寄送。

管理系統角色與帳號狀態

系統角色與專案角色是兩種不同的權限。只有 Admin 可以管理系統角色；後台管理員或 Project Manager 管理的是自己有權限之專案內的成員角色。

建立與修改專案

修改專案時要帶入版本欄位，避免兩位管理者同時編輯時，較晚送出的資料直接覆蓋前一次修改。

管理專案成員

加入成員或修改專案角色

移除專案成員

資料庫還應以 (ProjectId, UserId) 唯一限制防止重複成員，不能只依賴畫面檢查。

新增與修改 Task Item（後台使用者）

Task 的專案、標題與指派對象為必填，指派對象必須是有效專案成員，開始時間也不能晚於交付期限。

刪除 Task Item（後台使用者）

MVP 採軟刪除，因此一般清單不再顯示該 Task，但留言與稽核紀錄仍須保留，不能使用未經評估的 Cascade Delete 一併清除。

批次修改 Task 狀態（前台使用者）

批次更新不能成功一半、失敗一半。後端應在同一個交易中驗證並更新所有 Task，任何一筆失敗就全部回復原狀。

從詳細頁修改 Task（前台使用者）

Task Item 留言

E-mail 任務到期提醒

這個功能分成「找出需要提醒的 Task」與「寄送單封提醒信」兩段。兩段分開後，即使 Email 服務暫時失敗，也不必重新掃描全部 Task。

掃描到期任務

寄送單封提醒信

提醒排程每天執行一次，實際執行時間由系統設定。未完成的 Task 從到期前第 3 天開始每天提醒，到期當天仍會提醒；逾期後第 1 天至第 3 天繼續每天提醒，超過第 3 天便停止。同一個持續未完成的 Task，最多會在到期前第 3、2、1 天、到期當天，以及逾期第 1、2、3 天各產生一次提醒。查詢條件至少包含 Task 尚未完成、指派對象帳號仍啟用，以及 Email 已完成驗證。

為了避免排程重複執行或多台主機同時處理，寄送紀錄應以 Task、收件人與提醒規則建立唯一限制，並以原子操作取得寄送權。寄送前還要重新讀取 Task，避免使用者剛完成任務，系統卻仍寄出舊提醒。

Email 是外部服務；若服務已收信，但程式在寫回成功紀錄前中斷，重試仍可能造成極少數重複信件。若供應商支援 Idempotency Key，應使用寄送紀錄編號作為 Key。初次寄送失敗後，預設最多重試 3 次；達到上限後標記失敗並留下告警紀錄。本功能不另外限制寄件網域或訂定業務層的寄送速率，以 Email 服務回傳成功，且系統成功記錄寄送時間與服務回應編號，作為成功寄出的判定。

從流程找到要保存的資料

流程圖畫完後，下一個問題也跟著出現了。帳號驗證要保存驗證狀態，專案成員要記錄角色，Task 更新需要版本資訊，Email 提醒也要留下寄送與重試紀錄。這些資料不能只放在畫面上，伺服器重新啟動後仍要找得回來。

下一篇 Day8_要怎麼把資料記錄下來？用資料庫來保存紀錄吧，會先從關聯式資料庫的基本概念談起，再回頭看帳號、專案、成員與 Task 該怎麼拆成資料表。