事务处理在DDD设计模式中的建议

学习Golang要努力，但是不要急！今天的这篇文章《事务处理在DDD设计模式中的建议》将会介绍到等等知识点，如果你想深入学习Golang，可以关注我！我会持续更新相关文章的，希望对大家都能有所帮助！

众所周知，服务（控制器/用例）层是处理业务逻辑的， repo 用于处理数据库查询

现在我有：

func (s *orderservice) create(order models.order) (models.order, error) {
  ...
  user := models.user{
    contact: order.address.contact,
  }
  createduser, err := s.userrepo.save(user)   
  // err handling...

  order.user = user
  createdorder, err := s.orderrepo.save(order)
  // err handling...

  return order, nil
}

// user_repo.go
func (repo *userrepo) save(user models.user) (models.user, error) {
  err := repo.db.debug().save(&user).error
  // err handing...
  return user, nil
}

// order_repo.go
func (repo *orderrepo) save(order models.order) (models.order, error) {
  err := repo.db.debug().save(&order).error
  // err handing...
  return order, nil
}

我想应用 gorm db.begin() 事务变得更加灵活，而不是我当前的代码太静态。 那么我应该删除 gorm.db 存储库但是

我。通过params传入gorm.db??

tx := s.db.begin()
createduser, err := s.userrepo.save(user, tx)

tx := s.DB.Begin()
createdUser, err := tx.Create(&user)
if err != nil {
  tx.Rollback()
}
createdOrder, err := tx.Create(&order)  
if err != nil {
  tx.Rollback()
}
tx.Commit()

解决方案

根据 ddd，事务不应跨越聚合边界。

参考文献：

• https://martinfowler.com/bliki/DDD_Aggregate.html
• Defining Aggregate Boundaries

如果我们出于某种原因需要在事务中更新它们，您可能需要重新考虑它们是否应该成为某个聚合的一部分

在编写聚合存储库时，可以巧妙地将交易隐藏在存储库层

我通常遵循以下界面

// holds the business logic to modify the aggregate, provided by business layer
type AggregateUpdateFunction func (a *Aggregate) error
    
type Repository interface {
      Create(ctx context.Context, aggregate *Aggregate)
      Read(ctx context.Context, id string) *Aggregate
      // starts a read-modify-write cycle internally in a transaction   
      Update(ctx context.Context, id string, updateFunc AggregateUpdateFunction) error
}

以上就是《事务处理在DDD设计模式中的建议》的详细内容，更多关于的资料请关注golang学习网公众号！