别再重复造轮子去编写自定义工具函数和辅助代码。本技能教授整洁架构（Clean Architecture）和领域驱动设计（DDD）原则，帮助你编写可维护、可扩展的代码。
下载技能 ZIP
在 Claude 中上传
前往 设置 → 功能 → 技能 → 上传技能
开启并开始使用
测试它
正在使用“software-architecture”。 Review this UserService class for architectural issues: [ UserService class with database queries, API calls, and UI rendering all mixed together ]
预期结果:
发现架构问题：1) 关注点混合 - 数据库查询应属于 Repository 层，2) UI 渲染应在单独的视图组件中，3) API 调用应在专用服务中。推荐重构：拆分为 UserRepository（数据层）、UserService（业务逻辑层）和 UserView（表示层）。
正在使用“software-architecture”。 I need to implement payment processing. Should I build my own or use a library?
预期结果:
推荐：使用 Stripe 或 Paddle 而不是构建自定义支付处理。这些服务处理 PCI 合规性、循环计费、webhooks 和各种边界情况，自己构建需要数月时间。只有在你有现有解决方案无法满足的高度独特需求时，才考虑自定义实现。
正在使用“software-architecture”。 Design a module for order processing in an e-commerce app
预期结果:
推荐架构（DDD）：1) 订单实体（领域）：Order、OrderItem、OrderStatus。2) 仓库：OrderRepository、InventoryRepository。3) 服务：OrderService（placeOrder、cancelOrder）、PaymentService（processPayment）、InventoryService（reserveItems）。4) 避免的反模式：OrderController 执行业务逻辑、控制器中的数据库查询、通用的 OrderUtils 类。
安全审计
安全All static analysis findings are false positives. Detected 'backtick execution' patterns are markdown code emphasis formatting for library names and file examples. 'Weak cryptographic algorithm' detections are references to 'Clean Architecture' design pattern, not cryptography. 'System reconnaissance' patterns match legitimate software development guidance. This skill contains no executable code and provides educational architecture guidance only.
质量评分
你能构建什么
新项目架构设计
启动新项目时需要从第一天就建立坚实的架构基础
重构遗留代码
通过应用整洁架构原则改进现有代码库的代码质量
代码审查标准
为团队代码审查和 Pull Request 建立一致的架构指南
试试这些提示
Review this code component for architectural issues. Check for: generic naming (utils/helpers), business logic mixed with UI, file length over 200 lines, and functions over 50 lines. Suggest improvements following Clean Architecture principles.
I need to build a [feature] module. Design the architecture following DDD principles. Suggest domain-specific names for entities, services, and repositories. Define clear boundaries and separation of concerns.
I need to implement [feature] functionality. Search for existing libraries or services that solve this problem. Evaluate options based on: maintenance status, community adoption, documentation quality, and fit for my requirements.
Analyze this codebase for architectural anti-patterns: NIH syndrome (custom implementations instead of libraries), generic file names, poor separation of concerns, and deep nesting. Provide specific refactoring recommendations with examples.
最佳实践
- 在编写自定义代码前先搜索现有的库和服务，以减少维护负担
- 使用领域特定的名称如 OrderCalculator 和 UserAuthenticator，而不是通用的 utils 或 helpers
- 保持业务逻辑独立于框架，并与 UI 组件分离
- 应用早期返回模式以减少嵌套并提高代码可读性
避免
- 创建 utils.js 或 helpers.ts 文件存放不相关的函数，而不是使用领域特定的模块
- 将业务逻辑与 UI 组件混合，或将数据库查询直接放在控制器中
- 当存在成熟的库时，仍构建自定义的身份验证、状态管理或表单验证
- 使用通用的文件命名（common、shared、misc），没有清晰的领域目的