kratos微服务实战（三）kratos项目代码结构介绍

上文《kratos微服务实战（二）使用kratos模板生成项目代码》我们使用kratos模板生成了user-server的项目代码，之后可以看到整个项目的结构如下：

这个模板的整个结构代码说明示例如下：

  .
├── Dockerfile  
├── LICENSE
├── Makefile  
├── README.md
├── api // 下面维护了微服务使用的proto文件以及根据它们所生成的go文件
│   └── helloworld
│       └── v1
│           ├── error_reason.pb.go
│           ├── error_reason.proto
│           ├── error_reason.swagger.json
│           ├── greeter.pb.go
│           ├── greeter.proto
│           ├── greeter.swagger.json
│           ├── greeter_grpc.pb.go
│           └── greeter_http.pb.go
├── cmd  // 整个项目启动的入口文件
│   └── server
│       ├── main.go
│       ├── wire.go  // 我们使用wire来维护依赖注入
│       └── wire_gen.go
├── configs  // 这里通常维护一些本地调试用的样例配置文件
│   └── config.yaml
├── generate.go
├── go.mod
├── go.sum
├── internal  // 该服务所有不对外暴露的代码，通常的业务逻辑都在这下面，使用internal避免错误引用
│   ├── biz   // 业务逻辑的组装层，类似 DDD 的 domain 层，data 类似 DDD 的 repo，而 repo 接口在这里定义，使用依赖倒置的原则。
│   │   ├── README.md
│   │   ├── biz.go
│   │   └── greeter.go
│   ├── conf  // 内部使用的config的结构定义，使用proto格式生成
│   │   ├── conf.pb.go
│   │   └── conf.proto
│   ├── data  // 业务数据访问，包含 cache、db 等封装，实现了 biz 的 repo 接口。我们可能会把 data 与 dao 混淆在一起，data 偏重业务的含义，它所要做的是将领域对象重新拿出来，我们去掉了 DDD 的 infra层。
│   │   ├── README.md
│   │   ├── data.go
│   │   └── greeter.go
│   ├── server  // http和grpc实例的创建和配置
│   │   ├── grpc.go
│   │   ├── http.go
│   │   └── server.go
│   └── service  // 实现了 api 定义的服务层，类似 DDD 的 application 层，处理 DTO 到 biz 领域实体的转换(DTO -> DO)，同时协同各类 biz 交互，但是不应处理复杂逻辑
│       ├── README.md
│       ├── greeter.go
│       └── service.go
└── third_party  // api 依赖的第三方proto
    ├── README.md
    ├── google
    │   └── api
    │       ├── annotations.proto
    │       ├── http.proto
    │       └── httpbody.proto
    └── validate
        ├── README.md
        └── validate.proto

咱们在前面介绍了使用kratos生成项目之后，我们直接向对应的文件夹填充咱们的代码即可，所以这里我们来介绍下

1、api文件夹

api文件夹的主要作用是：

1、定义proto文件（包括不仅限于：service定义，messsage定义，接口定义等）
2、编译proto文件

所以这里的话，比如我们要给前端编写一个接口，那么类比java里面的controller层的操作都是在这里定义：

1、定义接口请求路径
2、定义接口方法
3、定义接口方法接收参数
4、定义接口方法返回参数

2、cmd

cmd文件夹的主要作用有：

1、使用wire进行自动注入
2、运行整个程序的main函数

3、configs

configs文件夹的主要作用用来编写配置文件的，我们大部分动态配置的参数都可以在这里的配置文件中进行配置。

4、internal

internal文件夹是kratos用来定义编写业务代码的，类比java的话，我们的model，service等层代码都是在这里进行编写的。

在internal文件夹下也分很多层的文件夹，分别对应ddd思想中每个模块的代码编写位置。类比java的话，实际操作如下：

1、编写model相关的domain代码放在biz目录下
2、编写读取配置文件等utils相关的类（比如java自己编写一个读取yaml文件格式的urils代码）放到conf目录下
3、编写业务数据层相关的代码放在data文件夹中，可以看做是java的dao层
4、对外暴露服务的注册相关代码放在server文件夹，类似于java中添加@restcontroller注解的效果。一般需要对外开放访问就操作这里。
5、编写service层代码放在service文件夹下。

5、third_party

third_party文件夹主要是放一些第三方调用相关的代码，类似java中把一些第三方的manager类相关的操作是放在这个文件夹下的。

最后来个简单的总结：