# Go-Quick-frame **Repository Path**: Silence_Y/go-quick-frame ## Basic Information - **Project Name**: Go-Quick-frame - **Description**: 适合写web的golang项目骨架 里面包含了基础设施 可直接入手写业务模块 - **Primary Language**: Go - **License**: Apache-2.0 - **Default Branch**: master - **Homepage**: None - **GVP Project**: No ## Statistics - **Stars**: 2 - **Forks**: 0 - **Created**: 2025-01-07 - **Last Updated**: 2025-01-15 ## Categories & Tags **Categories**: Uncategorized **Tags**: None ## README # 快速开发骨架 本项目采用 **领域驱动设计（DDD）** 和 **清晰架构** 风格进行构建，确保系统的可扩展性、可维护性和高内聚低耦合。项目按照功能模块划分，每个模块都有明确的职责，帮助开发者清晰定位各部分的作用。 本项目骨架封装了基本的设施 熟悉之后可以专注编写业务代码 ## 目录结构 ├── cmd │ └── api # API 入口模块，包含启动服务的入口 ├── configs # 配置文件存放目录 ├── global │ ├── consts # 存放全局常量定义 │ └── variable # 存放全局变量配置，如环境变量、配置文件等 ├── init # 项目初始化逻辑，主要用于配置加载和初始化服务 ├── internal │ ├── app │ │ └── user # 用户模块，包含用户相关的业务逻辑 │ │ ├── domain # 领域层，包含实体、值对象、领域服务等 │ │ ├── enum # 枚举类型，存放与业务相关的枚举定义 │ │ ├── event # 领域事件或应用事件 │ │ ├── httputils # HTTP 请求相关工具，DTO、验证、控制器等 │ │ │ └── user │ │ │ ├── dto # 数据传输对象（DTO），包括 Request、Response、Types │ │ │ ├── handler# 控制器或请求处理函数 │ │ │ └── verify # 请求验证逻辑 │ │ ├── middleware # 存放与 HTTP 请求相关的中间件 │ │ ├── repository # 数据访问层，处理与数据库、缓存等存储介质的交互 │ │ │ ├── cache # 缓存 │ │ │ ├── elastic # Elasticsearch │ │ │ └── mysql # MySQL │ │ └── service # 业务逻辑层，处理实际的业务操作 │ └── routes # 路由配置，定义路由和控制器之间的关系 ├── pkg │ └── utils # 工具类，存放公共功能库 │ ├── carbon # 日期时间相关的工具库 │ ├── gorm # GORM 相关的工具 │ ├── yml_config # 处理 YAML 配置文件的工具 │ │ └── ymlconfig_interf # 配置文件接口 │ └── zap_factory # zap 日志工厂工具 ├── scripts # 脚本目录，包含自动化脚本（如数据库迁移、构建脚本等） └── test # 测试目录，包含单元测试、集成测试等 ## 目录详细说明 ### 1. **cmd** - 启动入口 - **api**：包含项目的入口文件，用于启动服务并初始化相关依赖，通常在 main.go 中设置路由与依赖注入。 ### 2. **global** - 全局配置 - **consts**：存放全局常量的文件夹，定义了一些项目通用的常量。 - **variable**：存放全局变量配置，主要是一些动态的全局配置项。 ### 3. **init** - 初始化模块 包含项目的初始化逻辑，如数据库连接、日志系统、配置加载等。 ### 4. **internal** - 核心代码 internal 文件夹用于存放核心业务代码，遵循 **领域驱动设计（DDD）**，包括业务模块（如用户模块 user）以及相关服务层、仓库层等。 #### 4.1 **app/user** - 用户模块 - **domain**：领域层，包含核心领域模型，如 User 实体、Email、Address 等值对象。 - **enum**：定义与业务相关的枚举类型。 - **event**：事件驱动相关的模块，处理领域事件、应用事件等。 - **httputils**：HTTP 请求和响应处理相关的工具类，包括： - **dto**：数据传输对象，用于描述请求和响应的格式。 - **request**：用于接收客户端请求的数据结构（例如创建用户请求）。 - **response**：用于返回客户端响应的数据结构（例如返回用户信息）。 - **types**：公共的类型定义（如枚举、辅助结构）。 - **handler**：控制器或请求处理函数，负责接收请求并调用服务层进行业务处理。 - **verify**：输入验证相关的模块，负责请求数据的校验。 #### 4.2 **middleware** - 中间件 存放与请求处理相关的中间件模块，负责执行跨领域的逻辑，如认证、授权、日志记录等。 #### 4.3 **repository** - 仓库层 负责与数据存储层交互，通常通过接口定义不同类型的仓库： - **cache**：缓存相关的仓库实现（如 Redis）。 - **elastic**：Elasticsearch 数据库相关的仓库实现。 - **mysql**：MySQL 数据库相关的仓库实现。 #### 4.4 **service** - 业务逻辑层 包含应用层服务，负责执行实际的业务逻辑，如创建用户、删除用户等。 #### 4.5 **configs** - 配置文件 存放各种配置文件，例如数据库连接信息、API 密钥等配置。 ### 5. **pkg** - 公共库模块 该目录包含一些跨模块使用的公共库，方便其他模块复用，如工具函数库、第三方库封装等。 ### 6. **scripts** - 脚本 存放项目中使用的各种脚本文件，例如数据库迁移脚本、自动化构建脚本等。 ### 7. **test** - 测试模块 该目录包含所有的单元测试、集成测试等，按照功能模块进行组织，确保代码质量。 ## 模块间的交互 1. **控制器层**（位于 httputils/handler）会接收来自客户端的请求，并将请求数据传递给 **服务层**（位于 service）。 2. **服务层** 调用 **领域层**（位于 domain）来处理核心业务逻辑。 3. **仓库层**（位于 repository）通过实现具体的数据存取接口，提供对外数据访问的能力。 4. **事件**（位于 event）会触发应用事件或领域事件，并通过事件处理系统传递相关信息。 5. **中间件**（位于 middleware）则会在请求的处理过程中执行一系列跨领域的操作，如身份验证、请求日志等。 ## 结构体解决方案 在领域驱动设计（DDD）和清晰架构的设计中，Service 层的结构体可以包含业务逻辑和操作。对于大量的结构体，应该合理地分配它们的位置，以避免结构体定义过于混乱。以下是几个可以放置这些结构体的推荐目录和模块划分方案： ### 1. 专门创建一个 model 或 dto 目录 如果结构体本身主要是用于数据传输，或者它们是 DTO（数据传输对象）的一部分，那么可以考虑将这些结构体放在单独的 model 或 dto 目录下。特别是当你有大量的 DTO 或模型结构体时，集中管理这些结构体有助于保持清晰的目录结构。 internal ├── app │ └── user │ ├── model │ │ ├── user.go # 定义用户实体 │ │ ├── user_dto.go # 定义与用户相关的 DTO（请求/响应） │ │ └── user_validation.go # 与用户验证相关的结构体 │ └── service │ ├── user_service.go # 处理与用户相关的业务逻辑 │ └── auth_service.go # 处理认证相关的逻辑 ### 2. 将结构体放到 domain 层 internal ├── app │ └── user │ ├── domain │ │ ├── user_entity.go # 定义用户实体 │ │ ├── user_value_object.go # 定义用户相关的值对象 │ │ └── user_aggregate.go # 定义用户聚合根 │ ├── service │ │ ├── user_service.go │ └── model │ ├── user_dto.go # 定义与用户相关的 DTO（请求/响应） ### 3. 使用 repository 子目录中的结构体 如果结构体和数据访问有关，例如用来执行数据库查询、处理存储层交互，那么它们应当放在 repository 层下。此类结构体通常用于存储和数据持久化操作。 internal ├── app │ └── user │ ├── repository │ │ ├── user_repository.go # 定义与用户存储相关的操作 │ │ └── user_cache.go # 定义与用户缓存相关的操作 │ ├── service │ │ ├── user_service.go ### 4. 公共库目录（pkg） 如果这些结构体被多个业务模块共享（例如通用的结构体，或者是应用层各模块通用的业务实体），你可以将它们放到 pkg 目录中。这样可以避免将这些结构体重复定义在每个业务模块内。 pkg ├── dto │ ├── user_dto.go # 定义与用户相关的 DTO │ ├── order_dto.go # 定义与订单相关的 DTO ├── structs │ ├── common_structs.go # 公共的结构体，可能会被多个模块使用 │ ├── response_struct.go # 公共的响应结构体 ### 5. 根据结构体的用途进行分类 如果结构体非常多，你可以根据它们的具体用途进一步分类，例如按业务功能划分、按模型类型（DTO、实体、值对象）划分等。这样有助于提高项目的可维护性，确保业务逻辑层、领域层和数据传输层之间的隔离。 internal ├── app │ └── user │ ├── domain │ │ ├── user_entity.go # 领域模型，用户实体 │ │ ├── address_vo.go # 地址值对象 │ ├── service │ │ ├── user_service.go # 业务逻辑，处理用户操作 │ ├── dto │ │ ├── user_request.go # 请求 DTO │ │ ├── user_response.go # 响应 DTO │ ├── repository │ │ └── user_repository.go # 数据访问层 ### 总结 - 如果结构体是与业务逻辑紧密关联的，可以将它们放在 service 层的子目录中。 - 如果结构体是 DTO 或数据传输对象，可以将它们放在 model 或 dto 目录中。 - 如果结构体是领域模型的一部分，应该将它们放在 domain 层。 - 如果结构体是和数据存储相关的，可以放在 repository 层。 - 如果结构体是跨模块共享的，可以考虑放在 pkg 目录中作为公共库。 - 通过这种分层结构，可以使得项目中的各个部分更加清晰易维护。