在基于 Go 的 DDD 分层架构中，包含多个server的项目目录结构应如何组织？

原创

于 2025-08-29 09:35:09 发布 · 896 阅读

18 ·

CC 4.0 BY-SA版权

文章标签：

#golang #架构 #开发语言

在基于 Go 的 DDD 分层架构中，项目目录结构应如何组织？

在Golang项目中，采用DDD（Domain-Driven Design，领域驱动设计）的分层架构时，没有严格的标准规范，因为DDD更注重设计原则而非固定结构。但根据社区实践和常见实现，通常分为四层：Interface层（或Presentation层，处理外部交互如API）、Application层（协调用例和业务流程）、Domain层（核心领域模型和逻辑）、Infrastructure层（基础设施如数据库、外部服务）。这些层通过接口解耦，确保领域逻辑独立。

以下是一个典型的目录结构示例，基于多个来源的总结（如Medium文章、DEV Community和Talent500博客）。实际项目可根据规模调整，例如小型项目可能将所有层放在单个包下，大型项目则细分子包。结构通常置于internal/目录下，以防止外部导入。

project-root/
├── cmd/                  # 应用入口点，包含main函数
│   └── main.go           # 启动服务器或CLI的入口
├── internal/             # 内部包，核心代码
│   ├── application/      # Application层：用例服务，协调领域逻辑（不含业务规则）
│   │   └── services/     # 子目录示例
│   │       └── order_service.go  # 示例：订单用例服务
│   ├── domain/           # Domain层：核心业务模型、实体、值对象、领域服务、仓库接口
│   │   ├── model/        # 或直接按领域细分，如order/
│   │   │   └── order.go  # 示例：订单实体
│   │   ├── repository/   # 仓库接口（抽象数据访问）
│   │   │   └── order_repository.go
│   │   └── service/      # 领域服务（复杂业务逻辑）
│   │       └── order_domain_service.go
│   ├── infrastructure/   # Infrastructure层：具体实现，如数据库、外部API
│   │   ├── persistence/  # 数据持久化实现
│   │   │   └── order_repository_impl.go  # 仓库接口的数据库实现
│   │   ├── datastore/    # 数据存储具体实现（如SQL、NoSQL）
│   │   └── transport/    # 外部通信（如HTTP客户端）
│   │       └── http/     # HTTP相关实现
│   └── interfaces/       # Interface/Presentation层：外部适配器，如HTTP handler、CLI
│       ├── handlers/     # 处理程序
│       │   └── order_handler.go  # 示例：订单API handler
│       ├── routes/       # 路由定义
│       │   └── order_routes.go
│       └── middleware/   # 中间件（如日志、认证）
│           └── logging.go
├── pkg/                  # 可复用公共包（可选，非DDD核心）
│   └── utils/            # 工具函数
└── go.mod                # 模块定义