开发流程说明

在完成前面的架构设计说明之后，你已经了解了各个分层的职责划分。那么在实际开发中，当我们需要实现一个新需求时，应该如何落地？本节将从工程实践的角度，介绍一套推荐的开发流程，帮助你在现有架构下高效完成开发。

---

开发流程概览#

当需要实现一个新功能时，建议按照以下顺序进行：

1. 整理需求
2. 评估系统能力
3. 定义接口
4. 实现业务逻辑
5. 完善接口层

整个流程可以理解为：

需求 → 数据 → 接口 → 业务 → 输出

整理需求#

在开始编码之前，首先需要明确需求本身：

• 需要提供什么功能
• 接口需要接收哪些参数
• 最终需要返回什么结果

建议在这一步尽量做到清晰：

• 输入（Input）是什么
• 输出（Output）是什么
• 是否涉及状态变更

这一步的质量会直接影响后续开发的复杂度。

评估系统能力#

在明确需求后，需要评估当前系统是否已经具备支持能力：

数据库是否支持？#

• 如果​已支持：可以直接复用现有 Model
• 如果​不支持：
  • 新增或修改 Model
  • 同步更新数据库结构（migrate）
  • 如有需要，补充初始化数据（seed）

可参考：Model 设计说明

Repository 是否满足需求？#

• 如果现有方法可以满足：直接使用
• 如果不满足：
  • 在对应 Repository 中新增方法
  • 封装必要的数据查询或操作逻辑

可参考：Repository 设计说明

定义接口（Handler 层）#

确定接口所属模块后，开始定义接口结构：

• 在对应 Handler 模块中创建方法
• 在 internal/dto/input 中定义请求结构
• 在 internal/dto/resp 中定义响应结构

请求结构需要完成基础校验，例如：

• 类型校验
• 是否必填
• 长度限制
• 格式校验（基于 validator）

完成后：

• 在 internal/bootstrap/router.go 中注册路由
• 编写基础的 Handler 方法结构

可参考：Handler 设计说明

实现业务逻辑（Service 层）#

接下来进入核心业务开发阶段：

• 创建或使用对应的 Service
• 在当前模块的 dto.go 中定义 Service 入参与出参
  • 简单参数（如单个 int/string）可直接使用，无需额外结构

确保依赖注入正确：

• 在 internal/bootstrap/service.go 中注册 Service
• 按需注入对应 Repository

实现业务逻辑时建议：

• 所有数据操作通过 Repository 完成
• 复杂逻辑拆分为多个方法（common.go）
• Service 只负责流程编排

可参考：Service 设计说明、依赖注入设计

完善 Handler 实现#

最后回到 Handler 层，完成接口对接：

• 调用 Service 方法
• 处理返回结果
• 转换为响应结构（resp）
• 使用统一 response 返回

同时补充：

• 完整的 Swagger 注释（用于生成 API 文档）
• 错误处理（统一由 Handler 层处理）

总结#

一个完整的开发流程，本质上是围绕分层架构展开的：

• Model / Repository：解决数据问题
• Service：解决业务问题
• Handler：解决接口问题

通过按顺序拆解，可以避免：

• 直接写接口导致结构混乱
• 业务逻辑堆积在 Handler
• 数据操作散落在各层

且在实际开发中，可以始终遵循一个简单原则：

先想清楚数据，再设计接口，最后实现业务

这样可以让整个开发过程更加顺畅，也更符合当前项目的分层设计理念。

评论似乎卡住了，尝试刷新？✨