[[441824]]

回顧先簡單回顧一下 《Go工程化(九) 項目重構實踐》 如果還沒看過之前這篇文章可以先看一下：

在我們之前的項目目錄分層中，我們主要分為了五個塊：

• cmd/appname 是我們服務的入口，只負責啟動和依賴注入(使用 Wire)
• domain 或者 model 是我們的實體定義 + 接口定義
• server 負責實現我們在 proto 中定義的接口，在這一層中我們只做數據轉換，不寫業務邏輯
• usecase 負責實現我們的業務邏輯
• repo 負責數據操作， 僅做數據操作，不實現業務邏輯

在之前的文章中僅僅提到了一個非常簡單的示例，但是我們實際業務流程往往沒有那么簡單，就一個非常常見的例子，我們現在需要創建一篇文章，文章上需要關聯分類或者是標簽信息，這里至少就分兩步：

• 創建文章
• 關聯文章和標簽

這兩個創建操作需要保證一致性，我們需要在數據庫中使用事務，這時候我們的事務在哪里承載呢?

在 repo 層承載事務

其中最簡單也最直接的辦法就是在 repo 的 CreateArticle 方法中我們就使用事務去同時創建文章以及標簽之間的關聯關系。

• 我們不是所有的業務場景都需要關聯創建，有的場景下我們只需要一個單純的方法又怎么辦呢?
• 這么寫還有一個問題，我們把業務邏輯下沉到了 repo 中，后面我們還有其它關聯也這么搞么?

針對第一個問題，最簡單的辦法就是我們提供一個 CreateArticleWithTags 方法表示同時創建這兩者，如果我們需要一個獨立的 CreateArticle 再寫一個就好了。

但是隨著需求越來越多，可能后面還有需要和角色關聯的，和商品關聯的等等。

難道我們就一種邏輯寫一個方法么。想想就可怕。

還是在參數中加上很多可選的 options，然后在一個方法中不斷判斷。那我們還拿 usecase 做什么直接寫一起不更好么?

在 usecase 層承載事務

ok，所以直接在 repo 層里面來實現看上去好像行不通，那我們就把視線往上移動，我們在 usecase 來解決這個問題。

事務的能力是在 repo 上提供的，所以我們需要在 repo 層提供一個事務接口，然后在 usecase 中進行調用，保證是事務執行的就行。

使用 repo 層提供的事務接口

// domain/article.go 
// ArticleRepoTxFunc 事務方法 
type ArticleRepoTxFunc = func(ctx context.Context, repo IArticleRepo) error 
// IArticleRepo IArticleRepo 
type IArticleRepo interface { 
 Tx(ctx context.Context, f ArticleRepoTxFunc) error 
 GetArticle(ctx context.Context, id int) (*Article, error) 
 CreateArticle(ctx context.Context, article *Article) error 
} 

在 repo 中，我們可以像上面這樣定義，提供一個 Tx 方法，這個方法接受一個 ArticleRepoTxFunc 作為參數，這個函數中的 repo 是開啟了事務的 repo，通過這個 repo 調用的所有方法都是在事務中執行的。

// repo/article.go 
func (r *article) Tx(ctx context.Context, f domain.ArticleRepoTxFunc) error { 
 // 注意，這里的 r.db 是 *gorm.DB 
  // 在 gorm 中提供了 Transaction 的工具方法用于執行事務，這里我們就不自己寫了 
 return r.db.WithContext(ctx).Transaction(func(tx *gorm.DB) error { 
  // 我們使用事務的 tx 重新初始化一個 repo 
    // 這個 repo 后續的執行的數據庫相關的操作就都是事務的了 
  repo := NewArticleRepo(tx) 
  return f(ctx, repo) 
 }) 
} 

然后我們在 usecase 調用的時候就可以這樣。

// usecase/article.go 
func (u *article) CreateArticle(ctx context.Context, article *domain.Article, tagIDs []uint) error { 
 return u.repo.Tx(ctx, func(ctx context.Context, repo domain.IArticleRepo) error { 
  err := repo.CreateArticle(ctx, article) 
  if err != nil { 
   return err 
  } 
  var ats []*domain.ArticleTag 
  for _, tid := range tagIDs { 
   ats = append(ats, &domain.ArticleTag{ 
    ArticleID: article.ID, 
    TagID:     tid, 
   }) 
  } 
  return repo.CreateArticleTags(ctx, ats) 
 }) 
} 

這樣寫起來就整潔很多了，業務邏輯和我們最初的設計一樣，在 usecase 中實現了，repo 中我們也保持了簡單的原則。

這樣是不是就萬事大吉了呢?如果萬事大吉了這篇文章到這兒也就應該結束了，但是還沒有，說明我在實踐的過程中還碰到了問題。

問題很簡單，就是我們在 usecase 中不僅僅需要復用 repo 中的代碼，還有可能需要復用 usecase 中的代碼，不然我們就可能在 usecase 中出現很多相同的邏輯代碼片段，代碼的重復率就很高。

我們來看下面一個例子會不會發現有點什么不對。

// usecase/article.go 
func (u *article) A(ctx contect, args args) error { 
 err := u.CreateArticle(ctx, args.Article) // 包含事務 
  if err != nil { 
    return err 
  } 
  return u.UpdateXXX(ctx, args.XXX) // 這個方法中也使用了事務 
} 

這個方法內其實是開啟了兩個事務，這兩個事務之間互不相關，不符合我們需求。

在 usecase 層提供事務方法

// usecase/article.go 
type handler func(ctx context.Context, usecase domain.IArticleUsecase) error 
func (u *article) tx(ctx context.Context, f handler) error { 
 return u.repo.Tx(ctx, func(ctx context.Context, repo domain.IArticleRepo) error { 
  usecase := NewArticleUsecase(repo) 
  return f(ctx, usecase) 
 }) 
} 

我們在 usecase 中也創建了一個 tx 方法，和 repo 類似，在調用 tx 之后，handler 中的方法的需要都是用新的參數 usecase 這個新的 usecase 可以保證里面的 repo 調用都是事務的。

所以我們之前的 A 函數可以修改為這樣：

// usecase/article.go 
func (u *article) A(ctx contect, args args) error { 
 return u.tx(ctx, func(ctx context.Context, usecase domain.IArticleUsecase) error { 
  err := usecase.CreateArticle(ctx, args.Article) // 包含事務 
   if err != nil { 
     return err 
   } 
   return usecase.UpdateXXX(ctx, args.XXX) // 這個方法中也使用了事務 
 }) 
} 

這樣就沒有問題了么?我們 UpdateXXX 方法中也調用 u.tx 方法，這樣就會導致反復開啟事務，雖然在 gorm 的 Transaction 方法是支持嵌套事務的，但是我們還是不要濫用這個特性。

解決辦法很簡單，我們只需要在執行的時候判斷下就行了。

// usecase/article.go 
type article struct { 
 repo domain.IArticleRepo 
  isTx bool // 用于標識是否開啟了事務 
} 

然后我們在 tx 方法內：

func (u *article) tx(ctx context.Context, f handler) error { 
  // 如果已經開啟過事務了我們就直接復用就行了 
 if u.isTx { 
  return f(ctx, u) 
 } 
 return u.repo.Tx(ctx, func(ctx context.Context, repo domain.IArticleRepo) error { 
  usecase := &article{ 
   repo: repo, 
   isTx: true, 
  } 
  return f(ctx, usecase) 
 }) 
} 

總結

文章到這里就到尾聲了，同樣的問題，我們現在這么寫就可以了么?

對于我當前所遇到的一些需求來說已經可以解決了，當然這個方案并不完美，比如說我們涉及到多個 repo 的時候，當前的方法就沒法直接用了，還得進行一些改造，雖然我們要有遠見但是也不要想的太多，進化是優于完美的。