GitHubhttps://github.com/FindMyWay2Ting/OhMyGo项目地址一、什么是分层架构分层架构Layered Architecture是一种将系统按职责纵向切分的架构模式每一层只关注自己的事层与层之间通过定义好的接口通信。核心原则只有一条依赖方向只能单向传导每一层只依赖它的下层不能反向依赖。┌─────────────────────────────┐│ Controller 层 │ ← HTTP 入口接收请求│ 接收参数、参数校验 │└──────────────┬──────────────┘│ 业务参数▼┌─────────────────────────────┐│ Service 层 │ ← 业务逻辑编排│ 业务规则、事务控制 │└──────────────┬──────────────┘│ 数据操作▼┌─────────────────────────────┐│ DAO 层 │ ← 数据访问│ SQL 拼接、CRUD │└──────────────┬──────────────┘│ SQL▼┌─────────────────────────────┐│ MySQL / Redis / MQ │ ← 基础设施└─────────────────────────────┘二、OhMyGo 的五层结构OhMyGo├── router/ # 第一层路由注册HTTP 入口├── controller/ # 第二层接收请求参数解析├── service/ # 第三层业务逻辑编排├── dao/ # 第四层数据访问导航层├── model/ # 第四层附数据结构定义└── common/ # 基础设施MySQL / Redis / RabbitMQ / AI 模型每一层的职责非常清晰Router 层——路由注册Router 层不处理任何业务逻辑它只负责路由分组哪些接口需要鉴权哪些不需要中间件挂载JWT 校验在这里生效调用下层 ControllerController 层——请求处理职责接收 HTTP 请求做参数解析和响应组装调用 Service 服务层就相当于api层Controller 层的边界很清晰✅ 做参数校验binding required✅ 调用 Service 层✅ 组装 HTTP 响应❌ 不写 SQL❌ 不做业务规则判断只做调用和效验和一个响应Service 层——业务逻辑编排职责核心业务逻辑在这里这里是整个项目中最肥的一层,大部分功能都在这个里面。登录的一个代码展示Service 层的职责✅ 业务规则判断用户是否存在密码是否正确✅ 调用多个 DAO 层方法组合业务✅ 事务控制如果涉及多表操作❌ 不直接写 SQL委托给 DAODAO 层——数据访问职责对数据库的原子操作每个方法只做一件事。DAO 层的设计原则每个方法只做一次数据库操作不写业务逻辑只负责数据存取SQL 封装在这里对上层屏蔽细节Model 层——数据结构职责定义数据结构GORM 标签也在这一层。注意json:-这个标签Password 字段永不返回给前端这是在 Model 层做的安全约束三、为什么这样分层分层解决的问题问题一代码找不到在哪不分层的话Controller 里写 SQLService 里校验参数DAO 里做业务判断——三个月后接手鬼知道去哪改。分层之后想改接口定义 →router/想改参数校验 →controller/想改业务规则 →service/想改数据操作 →dao/问题二业务逻辑无法复用假设注册和修改资料都要校验邮箱格式。如果校验逻辑写在 Controller 里两个接口各写一遍如果写在 Service 层写一个方法两个地方都调用。问题三单元测试无法做如果 SQL、业务逻辑、HTTP 响应全写在一个文件里根本没法单独测试业务逻辑。分层之后Service 层只依赖 DAO 接口可以 mock 数据层做单元测试四、Controller 和 Service 到底怎么分这是最容易模糊的地方。记住一个判断标准「能不能在命令行里调用」——如果能那应该写在 Service 层。登录校验需要调用 DAO 查数据库这个逻辑可以脱离 HTTP 运行所以放 Service。而参数绑定c.ShouldBindJSON依赖 Gin 的Context只能在 Controller 里做。实操中的经验规则五、分层架构的常见问题问题一Service 层变成无脑代理这是最常见的反模式Service 层里必须有业务逻辑否则就别写直接在 Controller 里调 DAO。问题二跨层调用有时为了省事Controller 直接跳过 Service 调 DAO这样做短期省事但业务规则散落在 Controller 里日后改逻辑要改很多地方问题三分层过深有些项目分到五层、六层Controller → Service → Manager → Repository → DAO。层越多跨层调用的心智负担越大。三层Controller/Service/DAO加 Model 是大多数业务系统的最优解别为了架构感硬加层。六、OhMyGo 分层的实际收益回到 OhMyGo 这个项目。五层结构让它实现了一个很实用的特性更换 AI 模型无需改动业务代码。改动点在common/aihelper/基础设施层Service 层和 Controller 层完全不受影响。如果分层不清晰AI 模型切换可能要在十几个文件里改代码。这就是分层架构的核心价值隔离变化点让修改只发生在一个地方。七、总结