在 Go 服务层中如何优雅地管理事务?

在分层架构设计中,我们强调将业务逻辑与基础设施细节(如数据库访问)解耦。但在实际开发中,事务管理却常常打破这种分层的边界,成为架构设计中的一大挑战。

「分层架构中的事务困境」

在很多 Go 项目中,常见的做法是将数据库连接或事务对象直接传递到服务层(service layer),由服务层主导事务的开启、提交与回滚。

这种实现虽然直接有效,但也被视为一种事务泄漏的反模式(Transaction Leakage Anti-pattern):

增加了耦合度,服务层感知了事务对象,意味着数据访问层的实现细节被暴露。

虽然这是被广泛使用的一种"反模式",但在很多实际 Go 项目中我们还是能看到这种实现。

「聚合视角下的仓库设计」

先来聊一聊 Go 项目中另一个常见的误区:一张数据库表对应一个仓库(Repository)。这种方式在领域驱动设计中被认为是次优的。

领域驱动设计提出"聚合(Aggregate)"的概念:一组需要保持一致性的数据,应该视为一个逻辑单元进行统一管理。如果你按照表设计仓库,最终业务逻辑需要频繁跨多个仓库调用,进而需要复杂的事务共享逻辑。

因此,更好的做法是:

为每个聚合设计一个仓库(即使它涉及多个表)。

聚合内部事务由仓库统一处理。

「将事务逻辑封装在仓库中」

既然事务属于数据访问逻辑的一部分,那就应该将事务的生命周期管理放在仓库内部。下面是我们采用的解决方案:

go 复制代码
// domain/user.go

type User struct {
 ID   int    `gorm:"column:id" json:"id"`
 Name string `gorm:"column:name" json:"name"`
 Tags []Tag  `gorm:"foreignKey:UserID" json:"tags"`
}

func (u User) TableName() string {
 return "user"
}

type IUserRepo interface {
 Tx(ctx context.Context, f UserRepoTxFunc) error
 WithByID(id int) DBOption
 WithByName(name string) DBOption
 GetUser(ctx context.Context, opts ...DBOption) (User, error)
 CreateUser(ctx context.Context, user *User) error
 CreateTags(ctx context.Context, tags []Tag) error
}

type UserRepoTxFunc = func(ctx context.Context, repo IUserRepo) error
type DBOption func(*gorm.DB) *gorm.DB
c 复制代码
// domain/user_tag.go

type Tag struct {
 ID     int    `gorm:"column:id" json:"id"`
 UserID int    `gorm:"column:user_id" json:"user_id"`
 Tag    string `gorm:"column:tag" json:"tag"`
}

func (u Tag) TableName() string {
 return "tag"
}

首先在 repo 中,我们可以像上面这样定义,提供一个 Tx 方法,这个方法接受一个 UserRepoTxFunc 作为参数,这个函数中的 repo 是开启了事务的 repo,通过这个 repo 调用的所有方法都是在事务中执行的。

go 复制代码
// repo/user.go

func NewUserRepo(db *gorm.DB) domain.IUserRepo {
 return &user{db: db}
}

type user struct {
 db *gorm.DB
}

func (r *user) Tx(ctx context.Context, f domain.UserRepoTxFunc) error {
 return r.db.WithContext(ctx).Transaction(func(tx *gorm.DB) error {
  repo := NewUserRepo(tx)
  return f(ctx, repo)
 })
}

func (r *user) CreateUser(ctx context.Context, user *domain.User) error {
 return r.db.WithContext(ctx).Create(user).Error
}

func (r *user) CreateTags(ctx context.Context, tags []domain.Tag) error {
 return r.db.WithContext(ctx).Create(&tags).Error
}

func (r *user) WithByID(id int) domain.DBOption {
 return func(db *gorm.DB) *gorm.DB {
  return db.Where("id = ?", id)
 }
}

func (r *user) WithByName(name string) domain.DBOption {
 return func(db *gorm.DB) *gorm.DB {
  return db.Where("name = ?", name)
 }
}

func (r *user) GetUser(ctx context.Context, opts ...domain.DBOption) (domain.User, error) {
 var u domain.User
 db := r.db.WithContext(ctx)
 for _, opt := range opts {
  db = opt(db)
 }
 if err := db.Preload("Tags").Limit(1).Find(&u).Error; err != nil {
  return domain.User{}, err
 }
 return u, nil
}

服务层只需提供聚合级别的操作需求,仓库内部自动处理事务。在 usecase 中这样调用:

go 复制代码
// usecase/user.go

func NewUser(repo domain.IUserRepo) *User {
 return &User{repo: repo}
}

type User struct {
 repo domain.IUserRepo
}

func (u *User) CreateUser(ctx context.Context, user domain.User, tags []string) error {
 return u.repo.Tx(ctx, func(ctx context.Context, repo domain.IUserRepo) error {
  err := repo.CreateUser(ctx, &user)
  if err != nil {
   return err
  }

  if len(tags) == 0 {
   return nil
  }

  var uts []domain.Tag
  for _, v := range tags {
   uts = append(uts, domain.Tag{
    UserID: user.ID,
    Tag:    v,
   })
  }

  return repo.CreateTags(ctx, uts)
 })
}

虽然上述方案并不完美(比如当前事务封装只适用于单一仓库),但对于一些业务场景已足够解决了。

另外一点,上述代码也实现了可组合的查询选项,在 usecase 可以这样调用:

go 复制代码
// usecase/user.go

func (u *User) GetUserByID(ctx context.Context, ID int) (domain.User, error) {
 return u.repo.GetUser(ctx, u.repo.WithByID(ID))
}
相关推荐
蜗牛互联网8 小时前
WSL Containers GA:本地AI容器的生命周期、网络与治理验收
java·网络·人工智能·后端
Zhou1411369 小时前
SpringBoot_02_自动配置原理
java·spring boot·后端
子兮曰10 小时前
Node.js 50个优势场景盘点:一个人单干,为啥我多数时候只用它
前端·后端
IT_陈寒10 小时前
我花3小时debug,就因为JavaScript这个隐式转换坑
前端·人工智能·后端
程序猿阿越11 小时前
containerd如何拉取镜像
后端·kubernetes·源码阅读
一条小小yu11 小时前
为什么使用springboot
java·spring boot·后端
香瓜子rd11 小时前
MySQL InnoDB 并发控制核心原理:事务、隔离级别、MVCC 与锁机制
数据库·后端
RISCV_Explorer11 小时前
RISC-V RVV向量编程模型机制解析——vsetvl配置、掩码与尾元素策略及长度无关编程
后端·risc-v
对象存储与RustFS11 小时前
升级 RustFS 二进制不停机:一条一条换,留一条退路
后端·rust·开源
hasty11 小时前
限制写了却没生效:OpenTelemetry Go 的 Unicode 截断边界
开发语言·后端·golang