DDD设计模式中的交易建议

Question

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

现在我有：

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()

i. 在乡间路过。DB通过参数？？

tx := s.DB.Begin()

createdUser, err := s.UserRepo.Save(user, tx)

ii.或直接在服务层运行查询？？（但它打破了ddd的设计理念）

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()

Answer 1

根据 DDD，事务不应跨越聚合边界。引用：https://martinfowler.com/bliki/DDD_Aggregate.html定义聚合边界如果我们出于某种原因需要在交易中更新它们，您可能需要重新考虑它们是否应该成为某些聚合的一部分在编写用于聚合的存储库时，您可以整齐地隐藏存储库层中的事务我通常遵循以下界面// holds the business logic to modify the aggregate, provided by business layertype 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}

Answer 2

GORM 调用绝对应该在存储层中保持抽象。如果将实现细节（如事务句柄）泄露给业务逻辑，则存储层将与该特定的存储实现紧密耦合。在域驱动的世界中，人们可能应该以这样的方式对存储层的接口进行建模，即它具有与域对象一起操作业务逻辑所需的所有操作，而不是底层数据库提供的基本操作（重点是，如果您以后从SQL数据库切换到S3 REST API，则面向业务逻辑的接口将保持不变）。因此，相反（或在上面），我也会创建将在内部利用数据库事务的内容。OrderRepo.Save()OrderRepo.SaveAsNewUser() (Order, User, err)