核心定位
本 Skill 是一套后端架构设计教育文档，系统性地介绍三种主流架构模式：Clean Architecture（整洁架构）、Hexagonal Architecture（六边形架构/端口适配器模式）、以及 Domain-Driven Design（领域驱动设计）。它提供从概念理解到代码落地的完整路径，包含决策框架、分层结构、代码示例和常见反模式警示。
显著优点
1. 清晰的决策框架
通过简洁的表格帮助团队根据项目复杂度选择合适模式：简单 CRUD 无需过度设计，复杂业务域推荐 DDD，多外部集成场景首选 Hexagonal。这种"情境化推荐"避免了架构模式的滥用。
2. 可执行的代码示例
所有模式均配有完整的 Python 代码实现，涵盖 Entity、Port/Interface、Use Case、Adapter 各层。特别是 CreateUserUseCase 和 OrderService 示例，清晰展示了依赖注入和测试友好的设计。
3. 测试驱动设计
文档专门设置"Testing Benefits"章节，演示如何用 Mock Adapter 隔离测试业务逻辑，这是架构模式的核心价值之一。
4. 明确的反模式警示
"NEVER" 章节列出 7 条禁忌：贫血模型、框架耦合、胖控制器、抽象泄漏等，帮助开发者避开常见陷阱。
潜在局限
1. 语言局限性
代码示例仅使用 Python，对于 Java/Kotlin、C#、Go 等语言的开发者需要自行映射概念。某些语言特性（如 Java 的 Spring 生态）可能改变实现细节。
2. 缺少演进路径
文档假设"从零设计"的理想场景，但未详细说明如何从现有遗留系统（如 MVC 单体）逐步迁移到目标架构，这在实际重构中更具挑战。
3. 技术栈假设
示例默认异步 Python（asyncpg），对同步框架或关系型数据库以外的存储（MongoDB、Redis）覆盖不足。
适用人群
- 技术负责人/架构师：建立团队架构标准和代码审查清单
- 中级后端开发者：系统学习分层架构思想，突破 CRUD 开发瓶颈
- 准备重构的团队：为单体应用拆分微服务前建立内部边界
- 技术面试准备者：理解 DDD、整洁架构等高频考点
常规风险
| 风险点 | 说明 |
|--------|------|
| 过度工程化 | 文档明确警告"简单 CRUD 无需架构模式"，但开发者仍可能因追求"最佳实践"而引入不必要的复杂度 |
| 团队认知成本 | 分层架构需要全员理解依赖规则，新成员可能打破内层不依赖外层的约束 |
| 维护仪式化 | 严格的分层可能导致"为了分层而分层"的样板代码，需配合代码生成工具或框架降低负担 |
来源与可信度
由 GitHub 个人开发者 wpank 维护，属 T3 来源（个人/社区项目），但安全认证获得 S 级（95 分），无恶意代码、无网络通信、零第三方依赖。建议生产环境使用前进行内部代码审查并考虑 fork 自主维护。