Skip to content

程序目录结构

参考文档

目录结构

目录结构(总体结构参考project-layout)如下:

  • bin - 存储编译生成的二进制文件
  • cmd - 应用程序启动入口
  • mock - 自动化测试相关 参考文档 对应代码仓库
  • infra - 基础设施
    • manager - 基础设施管理器模块
    • redis - Redis缓存实例或接口封装 [仅供参考]
    • mqtt - Mqtt通信库实例或接口封装 [仅供参考]
    • gorm - Gorm数据库实例或者接口封装 [仅供参考]
    • kafka - Kafka消息队列实例或者接口封装 [仅供参考]
    • oss - Oss存储实例或者接口封装 [仅供参考]
  • adapter - 适配器(六边形架构) 参考文档
    • controller - 输入适配器
    • repository - 输出适配器(存储库的具体实现)
    • manager - 适配器管理器模块
  • domain - 领域模型 参考文档
    • module_1 - 领域模块1
    • module_2 - 领域模块2
  • docs - 设计和用户文档
  • config - 配置相关
  • common - 存放公共定义
  • utils - 存放辅助工具函数和全局常量

infra目录

infra目录用于存放类似redis、mqtt和kafka等基础设施代码,这样多个适配器可以共用一个基础设施。

  • infra - 基础设施目录
    • manager 基础设施管理器模块
    • orm - Orm基础设施模块
    • oss - oss基础模块目录

adapter目录

controller子目录

该目录用于存放输入适配器,目录下分布多个具体的输入适配器,示例如下:

  • controller - 输入适配器目录
    • openapi - 开放API
    • mobile_client - 移动客户端
    • erp_system - 某个第三方ERP系统

transferobject二级目录

该目录用于存放"传输对象"的定义,传输对象主要用于本服务(或系统)和第三方服务对接通信使用,有如下特点:

  1. 只用于数据传输(跟领域业务无关)
  2. 数据字段之间不一定有关联(和valueobject相比)
  3. 只有数据没有行为

repository目录

transferobject二级目录

该目录和controller目录下的transferobject二级目录作用相同

storeageobject二级目录

该目录用于存放"存储对象"的定义,存储对象主要用于表示数据库存储的形式,有如下特点:

  1. 只用于数据存储(跟领域业务无关)
  2. 只有数据没有行为
  3. 实现过程中更关注存储和查询性能

domain目录

domain目录下建议按照业务模块(可以适当范围大一些)创建二级目录,效果如下[示例]:

  • domain - 领域模型根目录
    • product - 产品管理模块
    • device - 设备管理模块
    • devops - 运维模块
    • monitor - 监控模块

然后在模块目录下面构建三级目录,效果如下:

  • product - 产品管理模块
    • aggregate - 聚合
    • entity - 实体
    • valueobject - 值对象
    • service - 领域服务
    • repository - 存储库的抽象接口定义

模块目录也可以支持多级,效果如下:

  • product - 产品管理模块
    • vendor - 产品厂商管理模块
    • type - 产品品类管理模块

上面关于多级模块目录的例子是不太合适的,没有必要将厂商和品类这么小的模块细化成二级模块目录。建议只有当一级存储库的抽象接口定义模块过于庞大繁杂时才使用二级模块。

!!! note "domain分模块目录的意义" 在domain分模块放置代码的意义在于,强迫开发人员关注实现"高内聚、低耦合"的模块,尽量不跨模块目录进行依赖。

aggregate子目录

本目录结构规范在其他参考文档的基础上,在和entityvalueobject同级目录下增加aggregate目录用于存放模块内属于 聚合根 的实体,模块外部只能通过引用aggregate目录的包,这样的写法虽然会导致代码量的少量重复,但是能够 清晰明确地展示聚合的存在和范围。

config目录

初步规划如下几类配置类型:

  • 全局配置
  • 基础设施配置
  • 适配器配置
  • 领域配置

config目录负责实现所有配置的加载、管理、销毁和刷新,并且对外提供封装好的配置信息读取接口,config目录外部并不需要关注过多的配置管理的底层细节。

目录结构如下:

  • config - 配置模块根目录
    • adapter - 存放适配器配置相关代码
    • domain - 存放领域配置相关代码
    • global - 存放全局配置相关代码
    • infra - 存放基础设施配置相关代码
    • source - 存放配置来源相关代码

adapter子目录

adapter目录用于存放对应适配器配置信息,内部目录结构和adapter目录保持一致,示例如下:

  • adapter - 适配器配置模块目录
    • openapi - 存放开发接口适配器配置

infra子目录

infra子目录用于存放基础设施配置信息,比如mysql、redis等,示例如下:

  • infra - 基础设施配置模块目录
    • mysql - 存放mysql配置
    • redis - 存放redis配置
    • oss - 存放oss配置

source子目录

source目录用于存放配置来源(例如:代码级别、本地配置文件、K8s字典表、Apollo配置中心)

  • apollo - Apollo配置中心
  • k8s - K8s字典表
  • local - 本地配置文件

common目录

common目录用于存放业务相关的公共常量,公共接口,根据模块的不同,需要把不同的常量和接口放在不同的文件下

  • common - 公共常量和接口定义
    • adapter.go - 存放适配器的常量定义和接口
    • global.go - 存放全局的常量定义和接口
    • infra.go - 存放基础设施的常量定义和接口

utils目录

utils目录用于存放辅助工具函数(例如:gin访问日志中间件、各个模块的名称、自定义错误处理、公共错误定义),与具体的业务无关