正文
如果你尝试学习Go，或者你正在为自己建立一个Poc或者一个玩具项目，这个项目布局是没有啥必要的，从一些简单的事情开始（一个main文件绰绰有余）。当有更多的人参与这个项目的时候，你讲需要更多的结构，包括需要一个tookit来方便生成项目的模板，尽可能大家统一的工程目录布局
本文章围绕github.com/golang-stan… 进行说明
/cmd
本项目的主干。 每个应用程序的目录名应该与你想要的可执行文件的名称相匹配（例如：/cmd/myapp）
/pkg/internal/internal
internal/pkg
/internal/pkg/internal/pkg/docs,/example,/pkg,/third_parth,/tools
/pkg/internal- /docs 放置一些项目说明文档
- /example 放置一些项目的使用示例
- /thrid_parth 三方的一些依赖文件，如：idl文件
- /tools 放置一些项目的脚手架工具，代码生成工具等
基础库项目布局
每个公司都应该为不同的微服务建立一个统一的kit基础包工具集。 基础库tookit为一个独立的项目，公司级建议只有一个，按照功能来拆分会带来不少的管理工作，因此建议并整合
kit包应该具备的特点
- 统一
- 标准库方式布局
- 高度抽象
- 支持插件
例如下面的布局
应用程序项目布局
/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交互，但是不应该处理复杂逻辑
布局示意图
数据流向
