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

kratos ddd

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

  1. kratos new <project-name>

生成的目录结构如下:

  1. .
  2. ├── Dockerfile
  3. ├── LICENSE
  4. ├── Makefile
  5. ├── README.md
  6. ├── api // 下面维护了微服务使用的proto文件以及根据它们所生成的go文件
  7. └── helloworld
  8. └── v1
  9. ├── error_reason.pb.go
  10. ├── error_reason.proto
  11. ├── error_reason.swagger.json
  12. ├── greeter.pb.go
  13. ├── greeter.proto
  14. ├── greeter.swagger.json
  15. ├── greeter_grpc.pb.go
  16. └── greeter_http.pb.go
  17. ├── cmd // 整个项目启动的入口文件
  18. └── server
  19. ├── main.go
  20. ├── wire.go // 我们使用wire来维护依赖注入
  21. └── wire_gen.go
  22. ├── configs // 这里通常维护一些本地调试用的样例配置文件
  23. └── config.yaml
  24. ├── generate.go
  25. ├── go.mod
  26. ├── go.sum
  27. ├── internal // 该服务所有不对外暴露的代码,通常的业务逻辑都在这下面,使用internal避免错误引用
  28. ├── biz // 业务逻辑的组装层,类似 DDD 的 domain 层,data 类似 DDD 的 repo,repo 接口在这里定义,使用依赖倒置的原则。
  29. ├── README.md
  30. ├── biz.go
  31. └── greeter.go
  32. ├── conf // 内部使用的config的结构定义,使用proto格式生成
  33. ├── conf.pb.go
  34. └── conf.proto
  35. ├── data // 业务数据访问,包含 cache、db 等封装,实现了 biz 的 repo 接口。我们可能会把 data 与 dao 混淆在一起,data 偏重业务的含义,它所要做的是将领域对象重新拿出来,我们去掉了 DDD 的 infra层。
  36. ├── README.md
  37. ├── data.go
  38. └── greeter.go
  39. ├── server // http和grpc实例的创建和配置
  40. ├── grpc.go
  41. ├── http.go
  42. └── server.go
  43. └── service // 实现了 api 定义的服务层,类似 DDD 的 application 层,处理 DTO 到 biz 领域实体的转换(DTO -> DO),同时协同各类 biz 交互,但是不应处理复杂逻辑
  44. ├── README.md
  45. ├── greeter.go
  46. └── service.go
  47. └── third_party // api 依赖的第三方proto
  48. ├── README.md
  49. ├── google
  50. └── api
  51. ├── annotations.proto
  52. ├── http.proto
  53. └── httpbody.proto
  54. └── validate
  55. ├── README.md
  56. └── validate.proto

推荐阅读