Golang 项目目录结构设计思考

前言

因进行 Golang 项目开发也有很长的一段时间。这里主要是对在项目结构上的设计做个记录。本文主要讲述在搭建项目框架时的一些设计和思考。主要思考点：什么样的项目结构才清晰易于使用？什么样的项目结构才是你想要的？

目录结构设计

MVC 可以说是接触最多，谈论也是比较多的一个项目结构。无论之前在进行 Java 开发或者是 C# 开发的时候基本都会有在使用的一种项目目录结构：控制器层处理输入，视图显示数据，实体模型。

所以在设计 Golang 项目目录结构的时候也会有一些 MVC 的影子在里面。在基于 gin 框架时 然后划分成路由、处理层、实体层。但是这样的结构肯定有很多问题，比如处理层所承载的业务逻辑功能太重，业务耦合太高，在后续的维护或者扩展肯定会有更大的问题，增加维护成本。

像 Java 中 spring /springboot 的框架，会根据相应的功能划分的比较清楚：

• Dao 层 进行和数据库交互
• Model 层 和数据库表对应
• Service 层 进行具体的逻辑实现
• Controller 层，处理的入口，但基本只进行一些入参和其他参数规则的娇艳
• Dto 一些入参映射以及响应参数的对应的类

所以使用的习惯下，会根据一个请求路由到和数据库交互这样的一个处理形成一个顺序链：router-handler-service-repository-entities 。每层负责处理专门的功能，从而进行解耦。

-- router （路由）
-- dto （入参和响应对应的结构体）
-- handler （其实就是 controller）
-- service （核心：主要处理业务路基）
-- repository （提供和数据库操作基本方法 CRUD 方法）
-- entities（与数据库表对应）

在使用时根据业务模块都划分，每个模块都有以上的一个处理链的文件，比如：

- entities
   - user.go
   - role.go
- repository(provider)
  - user.provider.go
  - role.provider.go
- modules
  - user
    - user.dto.go
    - user.handler.go
    - user.service.go
    - user.dto.go

将实体和数据库操作独立出来主要是因为这部分基本都是共用比较多的内容，所以没有划分到每个模块里。在 standard go[makeoptim.com/golang/stan…] 项目中的项目目录结构，每个文件都有其重要作用。所以我进行融合形成我现在经常用的目录结构：

- cmd （主干目录）
- config （配置文件）
- internal（不允许被其他项目导入使用的包）
	- entities
	- provider
	- modules
	- routers
- pkg （可以被外部程序安全导入的包）

以上就是我进行项目结构设计的一些思考。整个目录结构就是都要尽量避免出现循环调用的问题。其他还是可以看到很多缺点和不足。其中很大的点就是没有很好表现出 Golang 语言包的特性功能。

这里也推荐大家看看一些其他项目的框架目录设计，比如 goframe 、grafana等等

最后

软件架构设计的最终目标是能够用最小的人力成本来满足构建和维护该系统的需求。软件是为业务服务的，所以一个软件的好坏我想应该就是能够让开发者低成本学习和维护，并利用其帮助业务创造更大的利益。

所以感觉这句话很对：“软件架构师必须创建出一个可以让功能实现起来更容易、修改起来更简单、扩展起来更轻松的软件架构。”