目录结构 #

工程目录设计是代码分层设计的进一步落地

项目结构 #

• api 对外接口 对外提供服务的输入/输出数据结构定义。考虑到版本管理需要，往往以api/v1...存在。
• hack 工具脚本 存放项目开发工具、脚本等内容。例如，CLI工具的配置，各种shell/bat脚本等文件。
• internal 内部逻辑 业务逻辑存放目录。通过Golang internal特性对外部隐藏可见性。
  • cmd 入口指令 命令行管理目录, 可以管理维护多个命令行
  • consts 常量定义 项目所有常量定义
  • controller 接口处理 接收/解析用户输入参数的入口/接口层
  • dao 数据访问 数据访问对象, 这是一层抽象对象, 用于和底层数据库交互，仅包含最基础的 CURD 方法
  • logic 业务封装 业务逻辑封装管理，特定的业务逻辑实现和封装。往往是项目中最复杂的部分
  • model 结构模型 数据结构管理模块，管理数据实体对象，以及输入与输出数据结构定义。
    • do 领域对象 用于dao数据操作中业务模型与实例模型转换，由工具维护，用户不能修改。
    • entity 数据模型 数据模型是模型与数据集合的一对一关系，由工具维护，用户不能修改。
  • service 业务接口 用于业务模块解耦的接口定义层。具体的接口实现在logic中进行注入。
• manifest 交付清单 包含程序编译、部署、运行、配置的文件
  • config 配置管理 配置文件存在目录
  • docker 镜像文件 Docker镜像相关依赖文件，脚本文件等等。
  • deploy 部署文件 部署相关的文件。默认提供了Kubernetes集群化部署的Yaml模板，通过kustomize管理
• resource 静态资源 静态资源文件。这些文件往往可以通过 资源打包/镜像编译 的形式注入到发布文件中
• main.go 入口文件

对外接口 #

对外接口包含两部分：接口定义（api）+接口实现（controller）。

服务接口的职责类似于三层架构设计中的UI表示层，负责接收并响应客户端的输入与输出，包括对输入参数的过滤、转换、校验，对输出数据结构的维护，并调用 service 实现业务逻辑处理

业务实现 #

业务实现包含两部分：业务接口（service）+业务封装（logic）。

业务实现的职责类似于三层架构设计中的BLL业务逻辑层，负责具体业务逻辑的实现以及封装。

结构模型 #

model包的职责类似于三层架构中的Model模型定义层。模型定义代码层中仅包含全局公开的数据结构定义，往往不包含方法定义。

这里需要注意的是，这里的model不仅负责维护数据实体对象（entity）结构定义，也包括所有的输入/输出数据结构定义，被api/dao/service共同引用。这样做的好处除了可以统一管理公开的数据结构定义，也可以充分对同一业务领域的数据结构进行复用，减少代码冗余。