前言

因进行 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等等

最后

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

所以感觉这句话很对：“软件架构师有必要创建出一个能够让功用完成起来更简略、修正起来更简略、扩展起来更轻松的软件架构。”