Pythonによるアーキテクチャパターン

第6章. ユニット・オブ・ワーク・パターン

この作品はAIを使って翻訳されている。ご意見、ご感想をお待ちしている：[e-mail]

この章では、リポジトリパターンとサービスレイヤーパターンを結びつけるパズルの最後のピース、Unit of Workパターンを紹介する。

Repositoryパターンが永続ストレージの概念を抽象化したものだとすれば、Unit of Work（UoW）パターンは原子性演算子の概念を抽象化したものである。 これによって、最終的にサービス・レイヤーをデータ・レイヤーから完全に切り離すことができる。

図6-1は、現在、多くの通信がインフラのレイヤーをまたがって発生していることを示している。APIはデータベースレイヤーと直接会話してセッションを開始し、リポジトリレイヤーと会話してSQLAlchemyRepository を初期化し、サービスレイヤーと会話して割り当てを依頼する。

チップ

この章のコードは GitHubのchapter_06_uowブランチにある：

git clone https://github.com/cosmicpython/code.git
cd code
git checkout chapter_06_uow
# or to code along, checkout Chapter 4:
git checkout chapter_04_service_layer

図6-1. UoWなし：APIは3つのレイヤーと直接会話する。

図6-2はターゲット状態を示している。FlaskのAPIが行うことは2つだけだ：ユニット・オブ・ワークを初期化することと、サービスを呼び出すことだ。サービスはUoWと連携するが（UoWはサービスレイヤーの一部だと考えたい）、サービス関数自体もFlaskもデータベースと直接話す必要はない。

そして、Pythonの構文の素敵な部分、コンテキスト・マネージャー（ ）を使って全てを行う。

図6-2. UoWで：UoWがデータベースの状態を管理するようになった

作業単位はリポジトリと連携する

それでは、ユニット・オブ・ワーク（UoW、私たちは「ユーウー」と発音する）を実際に見てみよう。 レイヤーが完成したら、こんな感じになる：

作業単位の動作プレビュー(src/allocation/service_layer/services.py)

def allocate(
        orderid: str, sku: str, qty: int,
        uow: unit_of_work.AbstractUnitOfWork
) -> str:
    line = OrderLine(orderid, sku, qty)
    with uow:  
        batches