golang gin 项目代码组织结构能否像 python django 一样清晰

现有的组织结构

现在使用的 golang gin 的代码组织结构是延续了之前使用 php laravel 的组织方式， 主要目录包括：

• models
• controllers
• views / templates
• public

每个目录下都是一堆堆的 go 文件，例如 controllers 下是 user.go, article.go 等。

现有结构的弊端

现有组织结构用了快两年，经历的 gin 项目多了之后，弊端就逐渐显露了出来。例如：

• 所有 controllers 都在一个 package 内，就算是我一个人开发、维护，都很容易出现全局变量重名的情况。不得已就得加前缀，但是这样就增加了编码负担
• 新项目要复制旧项目的代码结构，做删减时，不方便，既要删除 models 中的，还要删 controllers，还要删 router 中的路由

参考 python django 框架的做法

里面一堆 app 目录，每个 package 包含一个子功能的所有代码，即将 model controller route 都放在一个目录下。

找到一个采用这种结构的 github 项目：

https://github.com/gothinkster/golang-gin-realworld-example-app

概要目录结构：

> tree
.
├── articles
│   ├── doc.go
│   ├── models.go
│   ├── routers.go
│   ├── serializers.go
│   └── validators.go
├── common
│   ├── database.go
│   ├── unit_test.go
│   └── utils.go
├── doc.go
├── hello.go
├── scripts
│   ├── coverage.sh
│   └── gofmt.sh
└── users
    ├── doc.go
    ├── middlewares.go
    ├── models.go
    ├── routers.go
    ├── serializers.go
    ├── unit_test.go
    └── validators.go

可以看到里面 users 跟 articles 就是两个独立的 package，类似 django 里 app 的概念。

唯一出乎意料的是这个 demo 里，route 和 controller 逻辑都写在了 routers.go 中。

实际上，我感觉把路由和接口函数都写在 controller.go 里完全可以接受，没有必要再单独搞一个 routers.go 文件。 就好像 spring boot 中在函数前面加注解实现路由一样，放在一块也挺清晰。

渐进式改造

先保持现有的组织结构，在加新功能时，使用新的结构。担心改动太多影响目前工期。