mcpField
S
software-architecture

software-architecture

github.com/neolabhq开发1.8k39 次安装9 周前更新
代码仓库

关于 software-architecture

面向开发者的软件开发技能，以 Clean Architecture 和 Domain Driven Design 指导架构与代码质量，涵盖模块设计、库选型和业务逻辑隔离。

主要功能

  1. 01Clean Architecture 与 DDD 指导
  2. 02优先选用现有库
  3. 03领域化命名规范
  4. 04业务与基础设施分离
  5. 05代码风格与复杂度规则

适用场景

  1. 01规划新应用的模块边界
  2. 02检查模块与职责设计
  3. 03评估使用现有库还是自定义代码

安装

复制下面的命令，在终端中运行。

$npx skills add https://github.com/neolabhq/context-engineering-kit --skill software-architecture

安装后在 Claude Code 中输入/software-architecture确认已加载。

详细介绍

软件架构开发技能

此技能为注重质量的软件开发和架构提供指导。它基于整洁架构和领域驱动设计原则。

代码风格规则

通用原则
  • 尽早返回模式：尽可能始终使用尽早返回，而非嵌套条件，以提高可读性
  • 通过创建可复用的函数和模块来避免代码重复
  • 将较长（超过 80 行代码）的组件和函数拆分成多个较小的组件和函数。如果它们无法在其他地方使用，则保留在同一文件中。但如果文件超过 200 行代码，则应拆分成多个文件。
  • 尽可能使用箭头函数，而非函数声明
最佳实践
库优先方法
  • 编写自定义代码之前，务必先搜索现有解决方案
    • 在 npm 中查找可解决该问题的现有库
    • 评估现有服务 / SaaS 解决方案
    • 考虑用于常见功能的第三方 API
  • 使用库，而不是自行编写工具函数或辅助函数。例如，使用 cockatiel，而不是自行编写重试逻辑。
  • 适合编写自定义代码的情况：
    • 领域特有的业务逻辑
    • 有特殊要求的性能关键路径
    • 外部依赖过于臃肿
    • 需要完全掌控的安全敏感代码
    • 经过全面评估后，现有解决方案仍无法满足要求
架构与设计
  • 整洁架构与 DDD 原则：
    • 遵循领域驱动设计和通用语言
    • 将领域实体与基础设施关注点分离
    • 使业务逻辑不依赖于框架
    • 明确界定用例，并使其保持隔离
  • 命名约定：
    • 避免使用通用名称：utils、helpers、common、shared
    • 使用领域专用名称：OrderCalculator、UserAuthenticator、InvoiceGenerator
    • 遵循限界上下文的命名模式
    • 每个模块都应有单一且明确的用途
  • 关注点分离：
    • 不要将业务逻辑与 UI 组件混在一起
    • 不要在控制器中编写数据库查询
    • 在上下文之间保持清晰的边界
    • 确保职责得到适当分离
应避免的反模式
  • NIH（非我发明综合征）：
    • Auth0 / Supabase 已存在时，不要自建身份验证
    • 不要自行编写状态管理，而应使用 Redux / Zustand
    • 不要自建表单验证，而应使用成熟的库
  • 糟糕的架构选择：
    • 将业务逻辑与 UI 组件混在一起
    • 直接在控制器中编写数据库查询
    • 缺乏明确的关注点分离
  • 通用命名反模式：
    • 包含 50 个互不相关函数的 utils.js
    • 作为杂物堆的 helpers/misc.js
    • 用途不明确的 common/shared.js
  • 请记住：每一行自定义代码都是一项需要维护、测试和编写文档的负担

评论

支持 Markdown