用途：把代码组织成同心层，依赖只能向内指向，使业务规则与框架、数据库、外部系统解耦。适合大于 500 LOC 且含业务逻辑的后端项目、需要替换数据库/框架/外部服务、希望不启动基础设施即可测试业务逻辑、构建多层服务。不适用于无真实业务规则的简单 CRUD API、脚本工具与原型。
主要能力：依赖规则——内层对外层一无所知，层级为 Presentation（HTTP、CLI、GraphQL）、Infrastructure（数据库、API、邮件，实现 Domain 端口）、Application（用例，编排 Domain 并定义端口）、Domain（实体，无外部依赖）。Domain 层只放纯业务规则；Application 层定义端口（接口）并编排实体；Infrastructure 层用具体技术实现端口；Presentation 层只处理协议关注点。
使用方式：标准目录为 src/domain（entities、value-objects、errors）、src/application（use-cases、ports、dto）、src/infrastructure（repositories、gateways、database）、src/presentation（controllers、routes、middleware）。禁止混层：实体不得直接调数据库，用例不得感知 HTTP 请求/响应，控制器不写业务逻辑。
限制与边界：前端 SPA 通常过重，可用状态管理与组件组合替代，仅当前端含大量业务逻辑时使用；可部分采用，先通过接口隔离外部依赖；DTO 与值对象可跨层但只能向内流动；只有 getter/setter 而逻辑全在服务里的贫血模型属反模式。