メインコンテンツまでスキップ

Prism Architectureとは何か？

はじめに​

Prism Architecture（プリズムアーキテクチャ）は、従来のドメイン駆動設計（DDD）、Onion Architecture、Clean Architectureのアプローチの限界に対処するために設計された現代的なソフトウェアアーキテクチャパターンです。関心の分離を維持しながら、特にGraphQLやSwiftUI、Jetpack Composeなどの現代的なUIフレームワークを使用するアプリケーションに、より柔軟性を提供します。

「Prism Architecture」という名称は、アーキテクチャが関心事を分離しながらも、ドメインモデルがアプリケーションのあらゆる側面に流れることを可能にする様子（プリズムが光をその成分色に分離するのに似ている）を反映しています。このパターンは実際のアプリケーション開発の経験を通じて進化してきました。

核心的な哲学​

Prism Architectureは、DDDやOnionのような伝統的なアーキテクチャが関心の分離という貴重な価値を提供する一方で、現代のアプリケーション開発—特にGraphQL、状態管理フレームワーク、SwiftUIのような宣言的UIテクノロジーを使用する場合—において摩擦を生み出すことがあると認識しています。

レイヤー間の過剰なマッピングや変換につながる硬直した境界を強制する代わりに、Prism Architectureは明確な責任と関心の分離を維持しながら、より自然なデータフローを可能にします。これは、アーキテクチャの純粋性と実装効率の両方を重視する開発者のために設計されています。

主要なレイヤー構造​

Prism Architectureは、それぞれ特定の責任を持つ6つの主要レイヤーで構成されています：

Core Layer（コア層 / 中核層）​

  • 目的: アプリケーションの基本的な概念を定義する安定したドメインモデルとコアプロトコルを保有する
  • コンポーネント: Entity、ValueObject、Enumeration、Core Protocol
  • 特徴: 安定しており、ほとんど変化せず、他のすべてのレイヤーからアクセス可能
  • 主要コンセプト: ValueObjectIDパターンを通じて強く型付けされた識別子を使用し、型の安全性とドメインの明確性を向上させる

Domain Layer（ドメイン層 / 領域層）​

  • 目的: アプリケーションのコア動作を実装するビジネスロジック、検証、ドメインルールを含む
  • コンポーネント: Domain Service、Validation Service、Rule Service、Domain Event
  • 特徴: ビジネスロジックに焦点を当て、Orchestration Layerと通信し、Core Layerにアクセスする
  • 主要コンセプト: Domain Eventはリアクティブパターンを可能にし、複雑なビジネスプロセスを一連のイベントと反応としてモデル化することを可能にする

Orchestration Layer（オーケストレーション層 / オーケ層 / 指揮層）​

  • 目的: 他のすべてのレイヤー間のフローを調整し、アプリケーション操作を管理する
  • コンポーネント: UseCase、Orchestration Service、Workflow Coordinator、Event Handler
  • 特徴: 中心的な通信者として、他のすべてのレイヤー間を仲介する
  • 主要コンセプト: シンプルなエンティティ中心のUseCaseから複雑なクロスドメインWorkflowまで階層的に構成される

Infrastructure Layer（インフラストラクチャ層 / インフラ層 / 基盤層）​

  • 目的: 外部通信、データアクセス、システムサービスを処理する
  • コンポーネント: データアクセス（GraphQL、REST）、System Service、External Service
  • 特徴: 外部システムとインターフェースし、Orchestration Layerと通信する
  • 主要コンセプト: GraphQL QueryServiceは、複数のドメインエンティティにまたがる可能性のある複雑なクエリのデータアクセスを最適化する

Presentation Layer（プレゼンテーション層 / プレゼン層 / 画面層）​

  • 目的: ユーザーインターフェースとユーザーインタラクションを管理する
  • コンポーネント: UI Component、Presenter/ViewModel、Screen、Navigation Controller
  • 特徴: 柔軟な内部構造を持ち、Orchestration Layerと通信する
  • 主要コンセプト: PrismUI、MVVM、TCA、MVPなど、複数のUIパターンをサポートする

Common Layer（コモン層 / 共通層）​

  • 目的: 横断的なユーティリティとデータ転送オブジェクトを含む
  • コンポーネント: Utility、Enumeration、DTO、Display Object
  • 特徴: Infrastructure、Orchestration、Presentation Layerからアクセス可能（Domainからは不可）
  • 主要コンセプト: DTOはドメインエンティティと通信に使用されるデータ構造の間に明確な分離を提供する

Prism Architectureが伝統的なアプローチと異なる点​

ドメイン駆動設計（DDD）との比較​

DDDがバウンデッドコンテキスト内にエンティティを分離し、コンテキスト間の明示的な変換を必要とするのに対し、Prism Architectureはアプリケーションのすべての部分からアクセス可能な共有Core Layerでコアドメインモデルを使用します。これにより、適切なドメインモデリングを維持しながら、継続的なマッピングの必要性を減らします。

Onion Architectureとの比較​

Onion Architectureでは依存関係が内側だけを指すのに対し、Prism ArchitectureではCore Layerがすべてのレイヤーからアクセス可能で、より柔軟なアクセスパターンを可能にします。Orchestration Layer（Onionにおける「Application Layer」から名称変更）は、単なる境界ではなく、レイヤー間の能動的な調整役として機能します。

Clean Architectureとの比較​

Clean Architectureでは、内側のレイヤーが外側のレイヤーを認識しないという厳格な依存ルールを適用します。Prism Architectureでは、Core Layerがすべてのレイヤーからアクセス可能であり、他の通信はOrchestration Layerを通じて流れます。さらに、Prismでは、Core LayerのEntityは主にデータ構造であり、ビジネスロジックはDomain Layerに存在します。

主要なアーキテクチャパターン​

双方向イベントフロー​

  • Domain EventはDomain Layerで発生する
  • Orchestration LayerはDomain Eventを購読し、応答を調整する
  • Presentation LayerはUI更新のための通知を受け取る
  • Infrastructure Layerはイベント配信の技術的側面を処理する

階層的コンポーネント編成​

  • UseCaseはシンプルなエンティティ中心の操作を処理する
  • Orchestration Serviceは機能領域の操作を管理する
  • Workflow Coordinatorは複雑なクロスドメインプロセスを処理する
  • これにより明確な境界と責任が作成される

状態とインテント処理​

  • Stateはコンポーネント階層を下に流れる
  • ユーザーアクションはIntentやCommandとして上に流れる
  • これにより予測可能なデータフローパターンが作成される
  • 特に宣言的UIフレームワークで効果的

GraphQL最適化データアクセス​

  • 標準的なデータアクセスにはRepositoryパターン
  • 最適化されたGraphQLクエリには専用のQueryService
  • 集約境界を越えた効率的なデータ取得を可能にする
  • パフォーマンスを最適化しながらドメインの整合性を維持する

Prism Architectureの主な利点​

  1. マッピングオーバーヘッドの削減: すべてのレイヤーからアクセス可能な共有ドメインモデルにより、類似モデル間の反復的なマッピングの必要性が減少。

  2. API柔軟性: 最適化されたクエリパフォーマンスのためにGraphQLをファーストクラス市民として設計していますが、アーキテクチャは従来のRESTAPIやその他の通信プロトコルも完全にサポート。

  3. UIフレームワーク互換性: SwiftUIやJetpack Composeのような現代的なリアクティブUIフレームワークとの相性が良い。

  4. 柔軟かつ構造化: 明確な関心の分離を維持しながら、実用的なデータフローを可能にする。

  5. レイヤー自律性: 各レイヤーは内部構造に関する自由度を持ち、チームが各領域で適切なパターンを使用できる。

  6. 自然なテスト境界: 明確なレイヤーの責任が、異なるテストアプローチの自然な境界を作成。

  7. ボイラープレートの削減: アーキテクチャ境界を維持するために必要なインフラストラクチャコードが少ない。

  8. 開発者エクスペリエンスの向上: 開発者にとってより直感的で、アーキテクチャの利点を維持しながら学習曲線を減少。

Prism Architectureを使用する場合​

Prism Architectureが特に適しているのは：

  • 現代的なUIフレームワークを使用するモバイルおよびデスクトップアプリケーション
  • データアクセスにGraphQLを使用するアプリケーション
  • 開発者エクスペリエンスと反復速度が重要なプロジェクト
  • 過度な儀式なしに良いアーキテクチャを維持したいチーム
  • アプリケーション全体で共有する必要がある複雑なドメインモデルを持つシステム

Prism Architectureは、以下を含むさまざまなコンテキストで効果的に使用できます：

  • 複雑なドメインモデルを含む、あらゆる規模のエンタープライズシステム
  • アーキテクチャの完全性を犠牲にすることなく開発速度を向上させたい組織
  • 最初からクリーンで保守可能なアーキテクチャを確立することが優先事項である新しいプロジェクト
  • コンポーネント間のデータフローの改善が望まれるレガシーシステムのモダナイゼーション

伝統的なDDD、Onion、またはClean Architectureアプローチは、特定の状況でまだ好まれる場合があります：

  • 完全なドメイン分離が絶対的な要件であるシステム
  • これらのアーキテクチャパターンへの既存の投資が移行コストを法外にする場合
  • 規制要件がシステムコンポーネント間の厳格な境界を義務付ける場合