DDD Standard Architecture Rules 是一套用于约束 DDD 应用架构的规则集合，核心目标是隔离业务意图与技术细节，并以长期演进和降低替换成本为设计导向。
一、总体架构与分层定义 系统必须明确划分为 Domain、Application、Infrastructure、Presentation 四个层级。每个文件只能属于一个层级，不得同时承担多层责任。分层目的是隔离业务意图与技术细节，不得为方便而合并层级。架构设计必须以长期演进与替换成本最小化为目标。
二、依赖方向（不可违反） 只允许以下单向依赖：Domain → Application → Infrastructure → Presentation。任何反向依赖一律视为架构错误。不得以类型、工具函数、barrel export 或 side-effect 间接形成反向依赖。依赖方向必须能在 TypeScript import 层级被静态分析出来。
三、Domain 层规则（业务核心） Domain 层必须是纯 TypeScript，不得依赖 Angular、RxJS、Signals、HTTP、Storage 或任何 framework，不得有 async / await、Promise 或 I/O 行为。Domain 层只描述“业务是什么”，不描述“怎么做到”。Domain 层只能包含 Entity、Value Object、Domain Service、Domain Interface。Entity 必须具有明确身份识别（identity）；Value Object 必须不可变（immutable）；Domain Service 只能表达无法自然归属于单一 Entity 的业务规则；Domain Interface 只描述能力，不描述实现方式。Domain 层不得知道数据来自哪里、如何存储、如何显示。
四、Application 层规则（业务流程与状态协调） Application 层负责用例（Use Case）与业务流程编排，是整个系统唯一的业务状态真相持有者。Application 层可以依赖 Domain，但不得反向依赖 Presentation 或 Infrastructure 实现。Application 层只能依赖 Infrastructure 定义的 interface，而非 concrete class。Application 层负责交易边界（transaction boundary）与流程顺序，不得包含 UI、DOM、Component、Template 相关概念，不得包含数据存取细节，不得将 framework 类型外泄给其他层。Application Facade 是 Presentation 唯一允许接触的入口。
五、Infrastructure 层规则（技术实现） Infrastructure 层只负责实现 Domain 或 Application 定义的 interface，可以依赖 framework 与第三方套件。Infrastructure 层不得包含业务规则或决策逻辑，不得自行成为状态真相，不得要求上层（Application / Domain）调整设计以配合技术细节，不得向外暴露 framework-specific 类型。Infrastructure 层可以被替换而不影响 Domain 与 Application。
六、Presentation 层规则（UI 与交互） Presentation 层只负责显示与用户交互，不得包含业务规则，不得自行定义业务状态真相。Presentation 层只能依赖 Application Facade，不得直接调用 Infrastructure，不得绕过 Application 直接操作 Domain。Presentation 层的状态只能是短生命周期的 UI state。
七、状态与责任边界 Domain 层不持有应用状态；Application 层集中管理所有业务状态；Infrastructure 层不得持有长生命周期业务状态；Presentation 层不得持有跨页或跨流程的业务状态。任一状态只能有单一权威来源（Single Source of Truth）。
八、Interface 与抽象规则 Interface 的定义位置必须属于需求方，而非实现方。Application 需要的能力，其 interface 必须定义在 Application 或 Domain。Infrastructure 只能实现 interface，不得反向定义需求。Interface 不得泄露技术细节。
九、Shared 与共用模块规则 shared 不得成为业务核心，不得包含业务状态或决策。若 shared 被多个 feature 视为业务依赖，则其层级必须上移至 Application 或 Domain。shared 仅允许存在纯工具、纯 UI、纯 stateless 元件。
十、结构与命名一致性 文件夹结构必须反映分层与责任。文件名与文件夹名称必须能直接推断其所属层级。不得出现语义与实际责任不符的命名。Barrel export 不得模糊层级边界。
十一、验证与演进规则 Domain 必须能独立于任何 framework 编译与测试。Application 必须能在无 UI 的情况下运行与测试。Infrastructure 必须可被 mock 或替换。Presentation 的替换不得影响业务逻辑。架构规则必须能通过 lint、test 或 CI 检查。
适用场景：采用 DDD 分层架构的 TypeScript 项目，尤其是需要长期演进、替换技术实现或保持业务逻辑独立于框架的工程团队。限制：资料未提供具体安装命令、代码示例、收费方式或平台支持信息，暂未提供。