domain-modeling

## account 的歧義 `account` 可能指： - **Customer**：付費購買方案的法人及其商業關係。 - **User**：可登入的自然人及其登入資格。 - **Customer 與其 Users 的合稱**：刪除整個組織及相關使用者。 - **方案或帳務關係**：終止訂閱、停止計費，但不一定刪除 Customer。 因此，「刪除 account」無法直接判斷應刪除哪個領域對象；「登入者不能再使用」也可能表示停用全部 Users，或僅撤銷其對該 Customer 的使用權。 ## 必須確認的問題 1. 刪除的是 Customer、某一個 User，還是終止方案？ 2. Customer 刪除後，其全部 Users 是否一律停用？ 3. User 停用後是完全不能登入，還是只能停止使用該 Customer 的服務？ 4. Customer 刪除是不可逆的終止，還是允許復原或重新啟用？ 5. 刪除何時生效：立即生效，還是於方案期間結束後生效？ 6. Customer 尚有未付款項、退款、折讓或爭議時，是否允許刪除？ 7. 刪除前已開立的發票須保留多久，以及哪些角色仍可查閱？ 8. 刪除後產生的退款、折讓或更正憑證，是否仍歸屬原 Customer？ 9. 發票上的法定買受人資訊是否必須保持原貌？ 10. 除發票必要資訊外，Customer 與 Users 的其他資訊應刪除、匿名化，還是繼續保留？ 11. 同一自然人日後是否可作為新的 User 加入另一個或重新建立的 Customer？ ## 邊界案例 - Customer 有有效方案，卻要求立即刪除。 - Customer 有逾期款項、付款處理中或尚未開立的發票。 - Customer 刪除後才發生退款、折讓、撤銷付款或發票更正。 - 某個 User 正在使用服務時，Customer 被刪除。 - Customer 的最後一位管理者要求刪除 Customer。 - 已停用 User 嘗試登入、重設登入憑證或接受邀請。 - Customer 刪除後，又以相同法人資料重新購買方案。 - 發票包含依法必須保留、但同時涉及隱私要求的資料。 - 發票保留期間屆滿，但仍有稅務、稽核或爭議需求。 - Customer 刪除與 User 停用部分成功、部分尚未生效。 ## 應追加到 `CONTEXT.md` 的內容 ```markdown ## Customer 刪除與 User 停用 ### Customer 刪除 Customer 刪除是 Customer 與服務之間商業關係的終止。刪除後，該 Customer 不再享有方案權益，也不能繼續使用服務。 Customer 刪除不等同於刪除其歷史發票。 ### User 停用 Customer 刪除時，屬於該 Customer 的全部 Users 均停用，而不刪除 Users。 停用的 User 不再具有登入或使用服務的資格。停用不改變該 User 曾屬於該 Customer 的歷史事實。 ### 發票保留 發票是 Customer 購買方案所形成的歷史交易憑證。 Customer 刪除後，其發票仍須保留。保留的發票仍歸屬於原 Customer，並維持其開立時的交易事實與買受人身分。 保留發票不代表原 Customer 或其 Users 仍具有方案權益、登入資格或服務使用權。 Customer 與 Users 的非發票資訊是否繼續保留，不因發票保留而自動決定。 ```

依題述定義，衝突在於 `Cancellation` 並非共享語意： - Ordering：取消尚未出貨的整張 `Order`。 - Billing：作廢單張 `Invoice`。 - 「部分 cancellation」未指出被取消的聚合與範圍，可能被誤解為部分取消訂單、取消部分數量，或作廢部分帳務文件。 迫使需求釐清的兩個情境： 1. 一張 Order 有三個尚未出貨的 line，客戶只不要其中一個：是取消整張 Order、移除單一 line，還是只取消該 line 的部分數量？ 2. 一張 Invoice 已涵蓋多個 Order line，其中一個 line 後來不出貨：是否作廢整張 Invoice、建立帳務調整，或完全不改 Invoice？ 確認需求為「部分取消 Order line，不作廢 Invoice」後，詞彙應分 context 處理： **Ordering context** - 更新 `Cancellation`：改稱 `Order Cancellation`，明確限定為取消整張尚未出貨的 Order。 - 新增 `Order Line Cancellation`：表示取消指定 Order line；若允許取消部分數量，還須另外定義數量語意。 **Billing context** - 更新 `Cancellation`：改稱 `Invoice Voiding` 或 `Invoice Void`，明確表示作廢整張 Invoice。 - 避免 `Partial Cancellation`：Billing 不應用它描述 Order line 的取消；Invoice 是否需要退款、折讓或其他調整仍未由已確認需求決定。

A. 不建立 ADR - 難逆轉：否，按鈕顏色可輕易調整。 - 沒有脈絡會令人意外：否，demo 採暫時性視覺設定並不反常。 - 存在真實取捨：否，未呈現需長期保留的架構或業務取捨。 B. 建立 ADR - 難逆轉：是，訂單完成後的資料修正模型會影響後續流程與稽核紀錄。 - 沒有脈絡會令人意外：是，使用者可能預期能直接修改已完成訂單。 - 存在真實取捨：是，稽核可追溯性與操作便利性之間存在明確取捨。 # 已完成訂單以具來源連結的修正單更正 ## Context 已完成訂單若可直接修改，操作較便利，但會削弱變更的可追溯性。稽核要求保留原始訂單及其後續修正之間的關係。 ## Decision 已完成訂單不得原地修改；任何更正都必須建立修正單，並連結至來源訂單。 ## Consequences - 保留原始紀錄，提升稽核能力與修正歷程的可追溯性。 - 使用者更正訂單時需要額外建立修正單，操作步驟增加。 - 系統與作業流程需明確呈現來源訂單和修正單之間的關係。