エンタープライズパターン

エンタープライズアプリケーションは、複雑なビジネスロジック・大量データの永続化・分散システム間の整合性といった課題を持つ。GoFパターンがオブジェクト設計レベルの語彙であるのに対し、エンタープライズパターンはアプリケーション全体のアーキテクチャ層での設計語彙だ。Martin Fowlerが2002年に著した『Patterns of Enterprise Application Architecture（PoEAA）』がその代表的なカタログである。

Repositoryパターンはデータアクセスのロジックをドメイン層から分離し、コレクションのような操作インターフェース（find・add・remove）でデータを扱う。Unit of Workはトランザクション境界内での変更を追跡し、一括コミットまたはロールバックを管理する。この2つは組み合わせて使われることが多く、ORMが自動実装していることも多い。Specificationパターンはビジネスルールをオブジェクトとして表現し、複合条件をandThen・orElseで組み合わせることができる。

CQRSはCommand Query Responsibility Segregationの略で、データの書き込み（Command）と読み取り（Query）のモデルを分離する。Event Sourcingは状態そのものではなくイベントのシーケンスを真の記録として保持し、任意時点の状態を再構築できる。Sagaパターンはマイクロサービス間の分散トランザクションを補償トランザクションによって実現し、Two-Phase CommitなしにBASE的な整合性を保つ。

コードレビューで着目するポイント

Repository内でビジネスロジックが混入していないか（クエリの組み立てを超えた処理）
Unit of Workのトランザクション境界がユースケース単位で正しく定義されているか
CQRSのQueryモデルがCommandモデルのスキーマに過度に依存していないか
Event Sourcingにおいてイベントスキーマが後方互換性を維持しているか
Sagaの補償トランザクションがすべての失敗シナリオをカバーしているか
Specificationが再利用可能な形でドメイン層に配置されているか
Repository/CQRSなどのパターンが複雑さに見合う規模のプロジェクトに適用されているか

典型的なアンチパターン

Fat Repository: Repository内にビジネスロジックが集積し、50種類以上のクエリメソッドを持つ巨大クラスになる。ドメインロジックがインフラ層に流出した状態であり、Specificationパターンによる分割が必要だ。

CQRS過剰適用: 単純なCRUDアプリにCQRS+Event Sourcingを適用し、実装量と運用コストが跳ね上がる。読み書きモデルが実質同じ場合はオーバーエンジニアリングになる。

Sagaの補償漏れ: 分散処理のある手順が失敗した際、それ以前のステップの補償トランザクションが実装されていない。部分的に確定した状態がデータに残り、整合性が壊れる。

参考リソース

Martin Fowler『Patterns of Enterprise Application Architecture』（Addison-Wesley、2002）
Vaughn Vernon『Implementing Domain-Driven Design』（Addison-Wesley、2013）
Microsoft Docs「CQRS pattern」 https://docs.microsoft.com/azure/architecture/patterns/cqrs
Chris Richardson「Saga pattern」 https://microservices.io/patterns/data/saga.html
Greg Young「CQRS and Event Sourcing」動画・論文（InfoQ、2012）