Go工程化项目布局

我正在参加「启航方案」

假如你尝试学习Go,或许你正在为自己建立一个Poc或许一个玩具项目,这个项目布局是没有啥必要的,从一些简略的工作开端(一个main文件捉襟见肘)。当有更多的人参加这个项目的时候,你讲需求更多的结构,包括需求一个tookit来便利生成项目的模板,尽或许大家一致的工程目录布局

本文章围绕github.com/golang-stan… 进行说明

/cmd

本项目的主干。 每个应用程序的目录名应该与你想要的可执行文件的称号相匹配(例如:/cmd/myapp)

不要在这个项目中放置太多的代码,假如你以为代码导入并在其他项目中运用,那么他应该位于/pkg目录中,假如代码不是可重用的,或许你不期望其他人重用他,请将该代码放到/internal目录中。

/internal

不期望对外进行同享的代码,internal目录中也能够放置一些子包结构,已做到愈加细化的切分,如:

|--internal
|   |
|   |--demo
|       |--biz
|       |--data
|       |--service

/pkg

外部应用程序能够运用的代码库,(例如:/pkg/publiclib)其他项目会导入这些代码库,所以放入到该目录下的代码要三思~注意:/internal目录是保证私有包不可导入的私有方法,由于他是由Go在编译时强制执行的。/pkg 仍然是一种更好的方式,能够显示的表示目录中的代码关于其他人来说是安全运用的好方法。

/pkg目录内能够参考GO规范库的组织形式,依照功用分类,/internal/pkg一般用于项目内的,跨多个应用的公共同享代码,可是其效果域仅在单个工程内。

|--pkg
|  |
|  |--cache
|  |   |--memcache
|  |   |--redis
|  |
|  |--conf
|      |--dsn
|      |--env
|      |--flagvar
|      |--paladin

/docs,/example,/pkg,/third_parth,/tools

这些跟上文说的/pkg/internal都同属根目录下的目录结构

  • /docs 放置一些项目说明文档
  • /example 放置一些项目的运用示例
  • /thrid_parth 三方的一些依靠文件,如:idl文件
  • /tools 放置一些项目的脚手架东西,代码生成东西等

根底库项目布局

每个公司都应该为不同的微服务建立一个一致的kit根底包东西集。 根底库tookit为一个独立的项目,公司级建议只有一个,依照功用来拆分会带来不少的管理工作,因此建议并整合

kit包应该具备的特点

  1. 一致
  2. 规范库方式布局
  3. 高度笼统
  4. 支持插件

例如下面的布局

|--cache
|    |--memcache
|         |--test
|    |--redis
|         |--test
|--conf
|    |--dsn
|    |--env 
|    |--flagvar
|    |--paladin
|          |--apollo
|               |--internal
|                     |--mockserver
|--container
|    |--group
|    |--pool
|    |--queue
|         |--aqm
|--database
|    |--hbase
|    |--sql
|    |--tidb
|--echo
|    |--types
|--log
|    |--internal
|         |--core
|         |--filewriter
|

应用程序项目布局

/api

API协议界说目录, xxapi.proto protobuf文件以及生成go的文件,我们一般把api文档界说在proto 文件中描绘

/configs

配置文件模板或许默许配置

/test

额外的外部测试应用程序和测试数据,你能够随时根据需求结构测试目录,关于较大的项目,有一个数据子目录是有意义的,例如你能够运用/test/testdata(假如你需求忽略目录中的内容)请注意,Go还会以“.”或许“_”最初的目录或许文件,因此在如何命名测试数据目录便利,有着很大的灵活性。

不应该包括/src目录

有些Go项目确实有src目录,这是由于开发人员一般有Java的开发布景。

/internal

/biz

事务逻辑的组装层,类似DDD中的domain,

/data

事务数据访问,包括cache和db等封装,完成了biz的repo接口,我们或许会把data和dao混合在一起,data侧重事务的意义,他所做的是将范畴对象从头拿出来,我们去掉了DDD的infra层,

/service

完成了api界说的服务层,类似DDD的applocation层,处理DTO到biz范畴实体的转化,(DTO->DO)搭档协同个类biz交互,可是不应该处理复杂逻辑

布局示意图

|--api
|--configs
|--test
|--internal
|       |--biz
|       |--data
|       |--service

数据流向

Go工程化项目布局