Unit of Workパターン - 変更をまとめて一貫して保存する

Unit of Workパターンとは、複数の変更を1つの作業単位としてまとめ、最後に一貫して保存するための設計パターンです。

一言でいうと

Unit of Workは「この処理で行った変更をまとめてコミットする」ための管理役です。

注文作成では、注文を保存し、在庫を減らし、支払い記録を作るかもしれません。途中で失敗したら、全部なかったことにしたい場面があります。

登場人物

Repositoryが「何を保存するか」を扱い、Unit of Workが「いつまとめて確定するか」を扱います。

処理の流れ

注文作成を例にします。

このまとまりがないと、注文だけ保存されて在庫が減っていない、といった不整合が起きやすくなります。

Repositoryとの関係

interface UnitOfWork {
 orders: OrderRepository;
 stocks: StockRepository;
 payments: PaymentRepository;
 commit(): Promise<void>;
 rollback(): Promise<void>;
}

ユースケースは複数のRepositoryを使いながら、最後にUnit of Workで確定します。

class CreateOrderUseCase {
 constructor(private readonly uow: UnitOfWork) {}

 async execute(input: CreateOrderInput): Promise<void> {
 try {
 const order = Order.create(input);
 await this.uow.orders.save(order);
 await this.uow.stocks.reserve(input.items);
 await this.uow.payments.createFor(order);
 await this.uow.commit();
 } catch (error) {
 await this.uow.rollback();
 throw error;
 }
 }
}

実際の実装では、ORMやDBクライアントのトランザクション機能を使います。

ORMとの関係

多くのORMには、Unit of Workに近い仕組みがあります。

ORMがUnit of Workを内部で持っている場合、独自に厚い抽象を作りすぎる必要はありません。

向いている場面

よくある誤解

すべての処理にUnit of Workが必要

参照だけの処理や単純な更新には不要です。複数の変更を一貫して扱いたい場面で使います。

Unit of Workに業務ルールを書く

Unit of Workは変更の確定を管理する役割です。業務判断はドメインやユースケースに置きます。

トランザクションを長く持てば安全

長いトランザクションはロックや性能問題を起こします。作業単位は短く保ちます。

チェックリスト

• 途中失敗時に戻すべき変更が複数あるか
• commit/rollbackの境界がユースケースと一致しているか
• トランザクションを長く持ちすぎていないか
• RepositoryとUnit of Workの責務が混ざっていないか
• ORMの機能で十分ではないか

まとめ

Unit of Workは、複数の変更を1つの作業単位として扱うための設計です。

Repositoryが保存対象を扱い、Unit of Workが変更の確定タイミングを扱うと考えると整理しやすくなります。

参考リソース

• Martin Fowler: Unit of Work
• Martin Fowler: Repository
• Microsoft: Implementing repository and unit of work patterns

関連記事

• リポジトリパターン
• 分散トランザクション
• ドメイン駆動設計（DDD）

×

PR

×

PR