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.gofunc (repo *UserRepo) Save(user models.User) (models.User, error) {  err := repo.DB.Debug().Save(&user).Error  // err handing...  return user, nil}// order_repo.gofunc (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 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

}

Answer 2

GORM 调用绝对应该在存储层中保持抽象。如果将实现细节（如事务句柄）泄露给业务逻辑，则存储层将与该特定的存储实现紧密耦合。

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