ddd-standard-architecture-rules（ddd 标准架构规则）

DDD Standard Architecture Rules

一、總體架構與分層定義

1. 系統必須明確劃分為 Domain、Application、Infrastructure、Presentation 四個層級。
2. 每個檔案只能屬於一個層級，不得同時承擔多層責任。
3. 分層的目的是隔離「業務意圖」與「技術細節」，不得為方便而合併層級。
4. 架構設計必須以長期演進與替換成本最小化為目標。

二、依賴方向（不可違反）

1. 只允許以下單向依賴： Domain → Application → Infrastructure → Presentation
2. 任何反向依賴一律視為架構錯誤。
3. 不得以型別、工具函式、barrel export 或 side-effect 間接形成反向依賴。
4. 依賴方向必須在 TypeScript import 層級即可被靜態分析出來。

三、Domain 層規則（業務核心）

1. Domain 層必須是純 TypeScript。
2. Domain 層不得依賴 Angular、RxJS、Signals、HTTP、Storage 或任何 framework。
3. Domain 層不得有 async / await、Promise 或 I/O 行為。
4. Domain 層只描述「業務是什麼」，不描述「怎麼做到」。
5. Domain 層只能包含：

- Entity - Value Object - Domain Service - Domain Interface

1. Entity 必須具有明確身分識別（identity）。
2. Value Object 必須是不可變（immutable）。
3. Domain Service 只能表達無法自然歸屬於單一 Entity 的業務規則。
4. Domain Interface 只描述能力，不描述實作方式。
5. Domain 層不得知道資料來自哪裡、如何儲存、如何顯示。

四、Application 層規則（業務流程與狀態協調）

1. Application 層負責「用例（Use Case）」與業務流程編排。
2. Application 層是整個系統唯一的業務狀態真相持有者。
3. Application 層可以依賴 Domain，但不得反向依賴 Presentation 或 Infrastructure 實作。
4. Application 層只能依賴 Infrastructure 定義的 interface，而非 concrete class。
5. Application 層負責交易邊界（transaction boundary）與流程順序。
6. Application 層不得包含 UI、DOM、Component、Template 相關概念。
7. Application 層不得包含資料存取細節。
8. Application 層不得將 framework 型別外洩給其他層。
9. Application Facade 是 Presentation 唯一允許接觸的入口。

五、Infrastructure 層規則（技術實作）

1. Infrastructure 層只負責實作 Domain 或 Application 定義的 interface。
2. Infrastructure 層可以依賴 framework 與第三方套件。
3. Infrastructure 層不得包含業務規則或決策邏輯。
4. Infrastructure 層不得自行成為狀態真相。
5. Infrastructure 層不得要求上層（Application / Domain）調整設計以配合技術細節。
6. Infrastructure 層不得向外暴露 framework-specific 型別。
7. Infrastructure 層可以被替換而不影響 Domain 與 Application。

六、Presentation 層規則（UI 與互動）

1. Presentation 層只負責顯示與使用者互動。
2. Presentation 層不得包含業務規則。
3. Presentation 層不得自行定義業務狀態真相。
4. Presentation 層只能依賴 Application Facade。
5. Presentation 層不得直接呼叫 Infrastructure。
6. Presentation 層不得繞過 Application 直接操作 Domain。
7. Presentation 層的狀態只能是短生命週期的 UI state。

七、狀態與責任邊界

1. Domain 層不持有應用狀態。
2. Application 層集中管理所有業務狀態。
3. Infrastructure 層不得持有長生命週期業務狀態。
4. Presentation 層不得持有跨頁或跨流程的業務狀態。
5. 任一狀態只能有單一權威來源（Single Source of Truth）。

八、Interface 與抽象規則

1. Interface 的定義位置必須屬於需求方，而非實作方。
2. Application 需要的能力，其 interface 必須定義在 Application 或 Domain。
3. Infrastructure 只能實作 interface，不得反向定義需求。
4. Interface 不得洩漏技術細節。

九、Shared 與共用模組規則

1. shared 不得成為業務核心。
2. shared 不得包含業務狀態或決策。
3. 若 shared 被多個 feature 視為業務依賴，則其層級必須上移至 Application 或 Domain。
4. shared 僅允許存在：

- 純工具 - 純 UI - 純 stateless 元件

十、結構與命名一致性

1. 資料夾結構必須反映分層與責任。
2. 檔名與資料夾名稱必須能直接推斷其所屬層級。
3. 不得出現語意與實際責任不符的命名。
4. Barrel export 不得模糊層級邊界。

十一、驗證與演進規則

1. Domain 必須能獨立於任何 framework 編譯與測試。
2. Application 必須能在無 UI 的情況下運行與測試。
3. Infrastructure 必須可被 mock 或替換。
4. Presentation 的替換不得影響業務邏輯。
5. 架構規則必須能透過 lint、test 或 CI 檢查。