architecture-patterns

Architecture Patterns - 后端架构模式智能体

技能概述

Architecture Patterns 是一个专注于后端架构设计的智能体技能，帮助开发者掌握 Clean Architecture、Hexagonal Architecture 和领域驱动设计（DDD）等经过验证的架构模式，构建可维护、可测试和可扩展的后端系统。

适用场景

1. 从零设计新后端系统

当你需要为复杂业务领域设计全新的后端架构时，该技能可以帮你选择合适的架构模式，定义清晰的模块边界和依赖规则，避免后期重构的高昂成本。

2. 重构单体应用

面对日益复杂、难以维护的单体应用时，该技能提供从紧耦合架构向松耦合架构迁移的具体步骤，包括如何划分领域边界、建立接口抽象和验证架构改进效果。

3. 建立团队架构标准

当团队需要统一的架构规范时，该技能帮助制定适合业务复杂度的架构模式选择指南、代码组织原则和最佳实践清单，提升团队协作效率和代码质量。

核心功能

架构模式选择与指导

根据业务复杂度、团队规模和可扩展性目标，推荐最匹配的架构模式（Clean Architecture、Hexagonal Architecture 或 DDD），并提供每种模式的核心原则、适用场景和实现要点。

领域边界与依赖规则定义

协助识别核心领域、子领域和通用语言，定义清晰的模块边界和接口契约，建立依赖倒置规则，确保业务逻辑与基础设施实现解耦，提升代码的可测试性和可替换性。

迁移路径与验证清单

提供从现有架构向目标架构迁移的分步指南，包括代码结构调整顺序、测试策略和架构健康度验证检查点，确保重构过程可控且可回滚。

常见问题

Clean Architecture 和 Hexagonal Architecture 有什么区别？

两者核心思想相同，都强调依赖倒置和业务逻辑与基础设施解耦。Clean Architecture 由 Uncle Bob 提出，强调同心圆分层和向内依赖；Hexagonal Architecture（六边形架构）由 Alistair Cockburn 提出，强调通过端口和适配器隔离应用核心。实际项目中，选择哪种更多是团队偏好和表达习惯的差异。

什么时候应该使用领域驱动设计（DDD）？

DDD 最适合具有复杂业务逻辑、需要团队协作长期维护的系统。如果业务规则简单、CRUD 为主，DDD 的额外复杂度可能不划算。信号包括：多个领域专家需要沟通、业务术语经常混淆、代码中到处散落着相似的业务逻辑、新功能开发需要理解大量隐含规则。

从传统架构迁移到 Clean Architecture 会增加很多开发成本吗？

初期会有学习曲线和架构调整成本，但长期来看可以降低维护成本和 bug 率。建议采用渐进式迁移：先在新模块中使用新模式，建立团队经验和模板；再逐步重构核心领域，每次重构后补充测试保护。不要试图一次性重写整个系统。