software-architecture

# 软件架构开发技能 此技能为面向质量的软件开发和架构提供指导。它基于整洁架构 (Clean Architecture) 和领域驱动设计 (DDD) 原则。 ## 代码风格规则 ### 通用原则 - **提前返回模式 (Early return pattern)**：尽可能使用提前返回，而不是嵌套条件，以提高可读性。 - 通过创建可重用的函数和模块来避免代码重复。 - 将长组件和函数（超过 80 行代码）分解为多个较小的组件和函数。如果它们在其他地方无法使用，请将其保留在同一文件中。但如果文件超过 200 行代码，则应将其拆分为多个文件。 - 尽可能使用箭头函数而不是函数声明。 ### 最佳实践 #### 库优先方法 - **在编写自定义代码之前，始终搜索现有解决方案** - 检查 npm 是否有解决该问题的现有库 - 评估现有服务/SaaS 解决方案 - 考虑针对常见功能的第三方 API - 使用库而不是编写自己的工具或辅助函数。例如，使用 `cockatiel` 而不是编写自己的重试逻辑。 - **当自定义代码确实合理时：** - 领域特有的特定业务逻辑 - 具有特殊要求的性能关键路径 - 当外部依赖项显得多余时 - 需要完全控制的安全敏感代码 - 经过彻底评估后，现有解决方案无法满足要求时 #### 架构与设计 - **整洁架构与 DDD 原则：** - 遵循领域驱动设计和通用语言 - 将领域实体与基础设施关注点分离 - 保持业务逻辑独立于框架 - 明确定义用例并保持其隔离 - **命名约定：** - **避免**通用名称：`utils`, `helpers`, `common`, `shared` - **使用**领域特定名称：`OrderCalculator`, `UserAuthenticator`, `InvoiceGenerator` - 遵循限界上下文命名模式 - 每个模块应具有单一、明确的目的 - **关注点分离：** - 不要将业务逻辑与 UI 组件混合 - 将数据库查询排除在控制器之外 - 保持上下文之间的清晰边界 - 确保职责的适当分离 #### 应避免的反模式 - **NIH (Not Invented Here) 综合症：** - 当 Auth0/Supabase 存在时，不要构建自定义身份验证 - 不要编写自定义状态管理，而应使用 Redux/Zustand