Go微服务：数据库模型与API模型的转换方案探讨

针对你描述的Go微服务三层架构（API/领域/存储）的模型转换问题，先逐一分析现有方案的问题，再给出解耦性更强的最优方案：

现有方案的问题分析 #

• 方案1：Storage层处理API模型转换
  完全违背分层架构的职责划分：Storage层的核心职责是数据持久化，不应该感知外部API的模型结构。同时让所有模块依赖API模型，会导致API模型的任何变更都需要同步修改所有层，耦合度极高，不可取。

• 方案2：Domain层处理API与Storage模型转换
  领域层是业务逻辑的核心，应该只聚焦于业务规则，不应该绑定API（表现层）或Storage（持久层）的具体模型。这种方案会让领域层被外部细节污染，降低其复用性（比如换一套API输出格式，就需要修改领域层代码）。

• 方案3：API层处理Storage模型转换
  直接违反了“不让存储模型泄露到API中”的共识，同时会让API层职责过载——API层本应只处理HTTP请求的解析与响应，把数据库模型的转换逻辑放在这里会导致代码臃肿，维护成本上升。

最优方案：引入独立领域模型，分层处理转换 #

核心思路是用领域模型作为中间层，让API层和Storage层分别与领域模型做转换，彻底隔离各层的模型依赖：

1. 定义独立的领域模型 #

在domain.go中定义只聚焦业务属性的领域模型，不包含任何序列化或数据库映射标签：

// domain.go
type User struct {
    ID           string
    BestFriendID string
}

2. Storage层：负责Storage模型 -> 领域模型的转换 #

Storage层只与领域模型交互，转换逻辑封装在Storage内部：

// storage.go
type UserRow struct {
    Id string `db:"user_id"`
    BestFriendId string `db:"best_friend_id"`
}

// 数据库查询方法
func (s *Storage) GetUserRow(id string) (UserRow, error) {
    // 执行数据库查询逻辑
}

// Storage内部转换：将数据库模型转为领域模型
func (row UserRow) ToDomain() domain.User {
    return domain.User{
        ID:           row.Id,
        BestFriendID: row.BestFriendId,
    }
}

3. Domain层：仅依赖领域模型处理业务逻辑 #

领域层完全不感知API或Storage的模型，只基于领域模型实现业务规则：

// domain.go
type Domain struct {
    db storage.Storage
}

func New(db storage.Storage) *Domain {
    return &Domain{db: db}
}

func (d *Domain) GetUserById(id string) (domain.User, error) {
    userRow, err := d.db.GetUserRow(id)
    if err != nil {
        return domain.User{}, err
    }
    
    // 这里添加业务逻辑（比如验证用户有效性、权限检查等）
    domainUser := userRow.ToDomain()
    return domainUser, nil
}

4. API层：负责领域模型 -> API模型的转换 #

API层只与领域模型交互，转换逻辑封装在API内部：

// api.go
type User struct {
    Id string `json:"id"`
    BestFriend User `json:"bestFriend"`
}

func (s *Server) handleGetUser(w http.ResponseWriter, r *http.Request) {
    id := mux.Vars(r)["id"]
    domainUser, err := s.dom.GetUserById(id)
    if err != nil {
        http.Error(w, err.Error(), http.StatusInternalServerError)
        return
    }
    
    // API内部转换：将领域模型转为API响应模型
    apiUser := toAPIUser(domainUser)
    json.NewEncoder(w).Encode(apiUser)
}

// 转换辅助函数
func toAPIUser(domainUser domain.User) User {
    // 若需要获取BestFriend的完整信息，可在此调用Domain层的查询方法
    return User{
        Id: domainUser.ID,
        BestFriend: User{
            Id: domainUser.BestFriendID,
        },
    }
}

方案优势 #

• 职责单一：各层只处理自身核心职责+与领域模型的转换，边界清晰
• 低耦合：API模型或Storage模型的变更，仅需修改对应层的转换逻辑，不会影响其他层
• 可复用性：领域模型和业务逻辑可以独立于API和存储方式复用，比如新增GRPC接口时，只需要新增GRPC层与领域模型的转换即可

内容的提问来源于stack exchange，提问作者Aaron Meier