Skip to main content

项目结构

我们创建了 kratos-layout 作为使用 kratos new 新建项目时所使用结构,其中包括了开发过程中所需的配套工具链( Makefile 等),便于开发者更高效地维护整个项目,本项目亦可作为使用 Kratos 构建微服务的工程化最佳实践的参考。

kratos ddd

使用如下命令即可基于 kratos-layout 创建项目:

kratos new <project-name>

生成的目录结构如下:

  .
├── 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

推荐阅读