📌

どのレイヤー（層）でトランザクションを実装すべきか

2024/02/28に公開

Golang

はじめに

こんにちは。クラウドエース株式会社で主にアプリケーション開発を担当している水野です。

今回は、どのレイヤー（層）でトランザクション実装すべきかについてご紹介します。

結論から言うと、usecase 層と infrastructure 層で実装します。
各層で実装することは以下です。実装内容は抽象化（カプセル化）させ、他の層では意識させないような構成にします。

層	実装内容
usecase	どの処理に対して整合性を保つかと処理をどの順番で実施するか
infrastructure	DB 固有のトランザクション操作（コミットやロールバック等）とトランザクションの分離性

背景

DDD のアーキテクチャにおいて、以下のような構成があります。
※ 図の矢印は依存関係を示しています。（依存元→依存先）
alt text

層	役割	関心事
domain	ドメイン知識（ビジネスルール）を表現	ビジネス知識
usecase	domain 層で定義しているオブジェクトやメソッドを用いてユースケースを実現	機能の処理順序
presentation	クライアントとの入出力を定義	技術知識
infrastructure	DB や外部APIとの入出力を定義	技術知識

このように、層ごとに関心事の分離を行うことで、保守性の高い（変更容易性や再利用性等）アプリケーションを実現できます。
しかし、「トランザクション」においてはどうでしょうか。
トランザクションはビジネス領域においても、技術領域においても関心事がある内容です。
そういう曖昧なものは「ひとまず usecase 層に入れてしまえ」という方針になりがちです。
ですが、DB 固有の知識を usecase 層の関心事にしてしまっては、関心事の分離をするメリットが得られません。
そのため、関心事の分離を実現しつつトランザクション実装をする方法を模索してみました。

前提

1. クリーンアーキテクチャを採用している（オニオンアーキテクチャやレイヤードアーキテクチャも含む）

そもそもビジネス知識と技術知識を分離していないアーキテクチャを採用している場合、メリットは得られません。
そのため、オニオンアーキテクチャやレイヤードアーキテクチャを含むクリーンアーキテクチャを前提とします。

2. MySQL か PostgreSQL である

今回のご紹介では、MySQL と PostgreSQL のみを対象とします。
とくに、トランザクション分離レベルは DB エンジンの種類によって仕様が決まるため、他の DB エンジンは各自で調査してください。（もし調査した方はコメントに記載いただけると嬉しいです）

トランザクションにおける各レイヤーの関心事

各レイヤーには関心事において違いがあり、トランザクションにおいても同様のことが言えます。

infrastructure 層の関心事

infrastructure 層は、DB や外部 API との入出力を定義しており、技術知識に関心事を持ちます。逆にビジネス知識の関心事はできるだけ持たないようにすべきです。

トランザクションにおける infrastructure 層の関心事は以下です。

トランザクション開始、コミット、ロールバックの操作
トランザクションの分離性

usecase 層の関心事

usecase 層は、domain 層で定義しているオブジェクトやメソッドを用い、「ファイルを登録する」などのユースケースを実現しています。そのため、機能を実現するための処理順序に関心事を持ちます。逆に技術知識の関心事はできるだけ持たないようにすべきです。

トランザクションのおける usecase 層の関心事は以下です。

どの処理に対して、整合性を保つか
処理をどの順番で実施するか

方針

1. Unit of Work というデザインパターンを採用

設計として Unit of Work というデザインパターンを採用します。
Unit of Work とは、ビジネストランザクションとDB通信が1対1の関係になる設計方針です。
ドメインオブジェクトの取得や更新が発生する度にDB通信が発生するには、DB パフォーマンス上非効率です。
しかし、DB 処理をひとつの SQL クエリにまとめてしまうと、ビジネス知識が infrastructure 層に漏れてしまい、関心事の分離ができなくなります。
それを解決するのが Unit of Work です。

2. トランザクション分離レベルは、`REPEATABLE READ`または`SERIALIZABLE`とする

データの整合性を保つためには、トランザクション分離レベルを考える必要があります。

詳しい内容は割愛しますが、標準SQLトランザクション分離レベルをまとめると以下です。（PostgreSQLの公式ドキュメントをもとに作成）

分離レベル	ダーティリード	ファジーリード	ファントムリード
READ UNCOMMITTED	可能性あり	可能性あり	可能性あり
READ COMMITTED	安全	可能性あり	可能性あり
REPEATABLE READ	安全	安全	可能性あり
SERIALIZABLE	安全	安全	安全

トランザクション分離レベルは、基本的にはREPEATABLE READ、より厳密に制御したい場合はSERIALIZABLEを採用します。
ファジーリードは更新処理に対して、ファントムリードは追加処理に対しての現象です。

PostgreSQLの場合はREPEATABLE READにおいてもファントムリードは発生しません。
また、MySQL InnoDB は REPEATABLE READがデフォルト分離レベルです。
厳密な制御はパフォーマンスとトレードオフになるため、基本的にはREPEATABLE READを採用するのが良いでしょう。

実装方法

上記の各レイヤーの関心事の分離を実現した実装方法をご紹介します。

infrastructure 層

トランザクション実装

Uptrace が提供している ORM ライブラリの Bun を参考にしました。
引数に関数を持たせ、その関数が成功したか失敗したかを元にトランザクション制御する実装方法です。

トランザクション分離レベルの設定

TxOptions の IsolationLevel で設定ができます。

以下が実装例です。

client.go

type Client struct {
	*sql.DB
}

// DBクライアント作成
func NewClient() *Client {
    dbURI := "root:root@tcp(127.0.0.1:3306/dbName)?parseTime=true"
    dbPool, err := sql.Open("mysql", dbURI)
    if err != nil {
        log.Fatal(fmt.Errorf("sql.Open: %w", err))
    }
    ...(中略)...
    return &Client{dbPool}
}

// トランザクション
func (c *Client) RunInTx(ctx context.Context, fn func(ctx context.Context) error) error {
    // トランザクション分離レベルの設定をここで行う
    tx, err := c.BeginTx(ctx, &sql.TxOptions{Isolation: sql.LevelSerializable})
    if err != nil {
        return err
    }
    // context にトランザクション追加
    ctx = context.WithValue(ctx, c.CtxTxKey(), tx)

    var done bool
    // RunInTx()終了時に実行
    defer func() {
        if !done {
            tx.Rollback()
        }
    }()

    // 引数に格納されたfn関数を実行
    if err = fn(ctx); err != nil {
    	return err
    }

    // 引数に格納されたfn関数が成功したら、doneをtrueにする
    done = true
    if err = tx.Commit(); err != nil {
    	return err
    }

    return nil
}

// トランザクション用のcontext キー
type TxKey string

func (c *Client) CtxTxKey() TxKey {
    return "tx"
}

func (c *Client) TxFromCtx(ctx context.Context) *sql.Tx {
    tx, ok := ctx.Value(c.CtxTxKey()).(*sql.Tx)
    if !ok {
    	return nil
    }
    return tx
}

SQL クエリの実装

context によって、この処理がトランザクション対象なのかを判断します。

// context からトランザクションを取得
if tx := TxFromCtx(ctx); tx != nil {
    // context にトランザクションがある場合は、トランザクションの DB 処理を実施
} else {
    // context にトランザクションが無い場合は、通常の DB 処理を実施
}

usecase 層

RunInTx() による DB 実装の隠蔽化により、usecase 層では「どの処理に対して、整合性を保つか」と「処理をどの順番で実施するか」にのみ関心を持たせることができます。

// func(ctx context.Context) error {} で記述した処理はトランザクション対象となる
if err = RunInTx(ctx, func(ctx context.Context) error {
    newSample, err := NewSample(ctx)
    if err != nil {
        return err
    }

    if exist, err := ExistSample(ctx); err != nil {
        return err
    } else if exist {
        return fmt.Errorf("sample already exists")
    }

    if err = AddSample(ctx, newSample); err != nil {
        return err
    }

    return nil
}); err != nil {
    return err
}

さいごに

今回は、どのレイヤー（層）でトランザクション実装すべきかについてご紹介しました。
結論は、usecase 層と infrastructure 層での実装です。
各層で実装することは以下です。実装内容は抽象化（カプセル化）させ、他の層では意識させないような構成にします。

層	実装内容
usecase	どの処理に対して整合性を保つかと処理をどの順番で実施するか
infrastructure	DB固有のトランザクション操作（コミットやロールバック等）とトランザクションの分離性

関心事の分離は、複雑なシステムであるほど実装レベルでの適用が難しくなると思います。
そんなお悩みの方に少しでも役に立つ情報であると願っています。