Part 6
案件追蹤系統完整實戰

01｜案例與完成範圍

02｜把 ChatGPT 放進 SDLC，而不是取代 SDLC

第一輪 Prompt：
先不要寫程式。針對案件狀態變更，找出會改變
權限、狀態機、資料一致性、稽核與驗收測試的未知事項。
依風險排序問 7 題；每題說明若不確認的後果。

03｜從需求建立可驗證設計

狀態轉換

資料庫先守住不變條件

create table cases (
  id uuid primary key,
  title varchar(200) not null,
  status varchar(30) not null
    check (status in ('Draft','Submitted','InReview','Approved','Rejected')),
  version integer not null default 1,
  updated_at timestamptz not null
);

create table case_status_history (
  id uuid primary key,
  case_id uuid not null references cases(id),
  from_status varchar(30) not null,
  to_status varchar(30) not null,
  changed_by uuid not null,
  reason text,
  changed_at timestamptz not null
);

04｜API 與核心實作（閱讀示範）

本節是閱讀示範：用來看懂設計意圖，不是可直接部署的實作。可執行的部分放在 §06。

public sealed record ChangeStatusRequest(
    CaseStatus TargetStatus,
    string? Reason,
    int ExpectedVersion);

public Result ChangeStatus(
    CaseStatus target, Guid actorId, string? reason, int expectedVersion)
{
    if (Version != expectedVersion)
        return Result.Conflict("CASE_VERSION_CONFLICT");

    if (!StatusTransitions.IsAllowed(Status, target))
        return Result.Invalid("INVALID_STATUS_TRANSITION");

    var previous = Status;
    Status = target;
    Version++;
    UpdatedAt = DateTimeOffset.UtcNow;
    _history.Add(CaseStatusChanged.Create(
        Id, previous, target, actorId, reason, UpdatedAt));

    return Result.Success();
}

上面那段版本檢查，擋不住兩個服務實例

if (Version != expectedVersion) 是記憶體內的比對。它能擋掉「客戶端拿著舊版本送出」，但擋不住「兩個請求各自讀到同一筆舊資料、各自比對通過」。下面這個時序，兩邊都會通過檢查：

版本必須參與寫入條件

真正的關鍵機制，是把版本放進資料庫更新的 WHERE 條件，再用影響列數判斷有沒有成功。EF Core 的 optimistic concurrency 就是這個做法：把 concurrency token 放進更新條件，找不到符合舊 token 的列時，回報並行衝突。

-- 概念 SQL；不是可直接部署的完整 repository 實作。
-- 角色、案件可見範圍、合法轉換與理由必填，仍須先驗證。
UPDATE cases
SET status = @target_status,
    version = version + 1,
    updated_at = @now
WHERE id = @id
  AND version = @expected_version
  AND status = @expected_status
RETURNING id, status, version;

-- 0 列：這次狀態轉換沒有完成；依 contract 處理衝突或不存在。
-- 1 列：才可以在同一個交易內寫入對應的 history。
-- 任一步驟失敗，整個交易必須回滾。

05｜測試不是只有 happy path

06｜畢業實作與驗收（可執行實驗）

這裡才是要動手跑的部分。請把它和 §04 的閱讀示範分開看：示範讓你看懂，實驗才產生證據。

驗收契約：要觀察到什麼，什麼不算數

07｜20 題綜合情境測驗

總分至少 85，且四個能力軸均達 70% 才通過。

官方技術參考

• Microsoft Learn：ASP.NET Core Web API
• Microsoft Learn：EF Core concurrency
• PostgreSQL：Constraints
• PostgreSQL：Transaction isolation

本章維護紀錄