Golang Kratos 系列：业务分层的若干思考（一）

在使用 Kratos 框架开发云服务的过程中，渐渐理解和感受到“领域层”这个概念和抽象的强大之处，它可以将业务和存储细节解耦、将业务和开发初期频繁变更的API结构，让Mock单元测试变得更加容易、对细节的变化更鲁棒。让业务代码摆脱技术细节依赖，使系统变更成本与业务复杂度解耦，领域层将领域层的放置位置应当遵循 “靠近使用者” 原则。以下是常见的分层方案和决策依据：

---

一、推荐架构（领域层独立）

.
├── internal
│   ├── domain   # 核心领域层（独立包）
│   │   ├── user.go        # 聚合根/值对象定义
│   │   ├── repository.go  # 仓储接口
│   │   └── service.go     # 领域服务  
│   │
│   ├── service  # 应用服务层
│   │   └── user.go        # 依赖domain包
│   │
│   └── data     # 数据层
│       └── user_repo.go   # 实现domain.Repository

---

二、分层决策依据

方案	优点	缺点	适用场景
领域层独立	1. 双向解耦 2. 明确分层界限	1. 多一个包目录 2. 需严格依赖管理	中大型项目 复杂业务逻辑
领域层在service	1. 减少包数量 2. service直接使用	1. data层需反向依赖service 2. 易产生循环引用	小型项目 快速原型开发
领域层在data	1. 数据层自包含	1. service层被迫依赖data 2. 破坏分层架构	不推荐

---

三、具体实施示例

1. 独立领域层（推荐）

// internal/domain/user.go
package domain

type User struct {
   
   
    ID   UserID
    Name string
}

type UserRepository interface {
   
   
    FindByID(context.Context, UserID) (*User, error)
}

// internal/service/user.go
package service

type UserService struct {
   
   
    repo domain.UserRepository // 依赖抽象
}

// internal/data/user_repo.go
package data

type