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

代替アーキテクチャとの比較

読了時間: 約10分

はじめに​

Prism Architectureを十分に理解するためには、他の確立されたアーキテクチャパターンと比較することが重要です。この文書では、Prism Architectureといくつかの一般的な代替アーキテクチャとの類似点と相違点を検証し、Prismが独自のメリットを提供する点や、既存のアプローチからインスピレーションを得ている点を強調します。

Prism Architectureと以下のアーキテクチャを比較します：

  • ドメイン駆動設計（Domain-Driven Design, DDD）
  • クリーンアーキテクチャ（Clean Architecture）
  • オニオンアーキテクチャ（Onion Architecture）
  • ヘキサゴナルアーキテクチャ（Hexagonal Architecture, ポートとアダプター）

PrismUI: 推奨プレゼンテーションパターン​

プレゼンテーション層については、Prism ArchitectureはPrismUIを推奨しています。これは、コアアーキテクチャとシームレスに連携するように設計された特殊なプレゼンテーションパターンです。PrismUIの特徴は次のとおりです：

  • 階層的プレゼンター構造: UIコンポーネント構造を反映した3階層のプレゼンター構造
  • インテントベースの通信: ユーザーアクションをUIからプレゼンターに伝えるための明示的なインテントオブジェクトの使用
  • 単方向の状態フロー: プレゼンターからUIコンポーネントへの予測可能な状態フロー
  • 宣言的UIサポート: SwiftUI、React、Flutterなどの最新のUIフレームワークと自然に連携

PrismUIと他のUIアーキテクチャパターン（MVVM、Redux/Flux、MVCなど）の詳細な比較については、専用のUIアーキテクチャ比較文書を参照してください。

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

ドメイン駆動設計は、ビジネスドメインを密接に反映したリッチなドメインモデルの作成に焦点を当てた包括的なソフトウェア開発アプローチです。

主な類似点​

  • リッチなドメインモデル: 両方のアプローチがビジネスコンセプトを捉えたドメインモデルを重視
  • 関心の分離: 両方が技術的な関心事とドメインの関心事を分離
  • ユビキタス言語: 両方がコードベース全体で一貫した用語を強調
  • ビジネス価値重視: 両方が技術的な関心事よりもビジネス要件を優先

主な相違点​

境界づけられたコンテキスト（Bounded Contexts）:​

  • DDD: コンテキスト間の明示的な変換を伴い、境界づけられたコンテキスト内でモデルを厳密に分離
  • Prism: アクセス可能なコア層で共有コアドメインモデルを使用し、変換のオーバーヘッドを削減

集約（Aggregates）と一貫性の境界:​

  • DDD: 一貫性のために厳格な集約境界を強制
  • Prism: 特にクエリ最適化のために、集約境界についてより柔軟

リポジトリの実装:​

  • DDD: リポジトリは通常、完全な集約と連携
  • Prism: 従来のリポジトリと特殊なクエリサービスの両方をサポート

実装の複雑さ:​

  • DDD: 多くの変換層により複雑な実装になる可能性
  • Prism: 変換を少なくし、実用的な実装を優先

それぞれを選ぶタイミング​

DDDを選ぶとき:

  • システムが同じ用語に対して異なる意味を持つ、真に異なる境界づけられたコンテキストを持つ場合
  • 集約境界の厳格な強制が必要な場合
  • 主に従来のデータベースとREST APIを使用している場合

Prismを選ぶとき:

  • オーバーヘッドが少なくドメインモデリングの利点が欲しい場合
  • GraphQLや他のクエリ最適化APIを使用している場合
  • ドメインの整合性とクエリ最適化の間でより柔軟性が必要な場合

クリーンアーキテクチャとの比較​

Robert C. Martinによって普及したクリーンアーキテクチャは、依存関係が内側を指す同心円状にコードを編成します。

主な類似点​

  • レイヤーの分離: 両方がレイヤー間に明確な境界を作成
  • ビジネスロジックの分離: 両方が外部の関心事からビジネスロジックを保護
  • テスト容易性: 両方のアーキテクチャがテスト容易性を考慮して設計
  • 依存関係のルール: 両方がレイヤー間の依存関係の方向を制御

主な相違点​

依存関係の方向:​

  • クリーン: 内側のレイヤーは外側のレイヤーを知らず、厳格な依存関係ルールがある
  • Prism: コア層は全レイヤーからアクセス可能で、他の依存関係はオーケストレーションを通じて流れる

データ構造の位置:​

  • クリーン: 各レイヤーには通常独自のデータ構造がある
  • Prism: レイヤー間でコア層エンティティを共有し、マッピングのオーバーヘッドを削減

中央調整:​

  • クリーン: ユースケースがレイヤー間を調整するが、権限は限定的
  • Prism: オーケストレーション層が全レイヤーの相互作用を積極的に調整

UI通信:​

  • クリーン: しばしばインターフェースとしてプレゼンター/コントローラーに依存
  • Prism: インテントベースの通信と階層的プレゼンターを使用

それぞれを選ぶタイミング​

クリーンアーキテクチャを選ぶとき:

  • コンポーネント間の最大限の分離が必要な場合
  • より厳格な境界のためにより多くのマッピングコードを書くことをいとわない場合
  • 各レイヤーに個別のモデルを持つことでシステムが恩恵を受ける場合

Prismを選ぶとき:

  • 類似したモデル間の繰り返しマッピングを減らしたい場合
  • レイヤー間のより柔軟な通信が必要な場合
  • 最新のリアクティブUIフレームワークを使用している場合

オニオンアーキテクチャとの比較​

Jeffrey Palermoによって説明されたオニオンアーキテクチャは、中心にドメインモデルを置いた同心円状のレイヤーにコードを編成します。

主な類似点​

  • ドメイン中心: 両方ともドメインの概念を中心に置く
  • レイヤーアプローチ: 両方が関心事を分離するためにレイヤーを使用
  • 外部からの独立: 両方が外部の関心事を外側のレイヤーに分離
  • 依存性の逆転: 両方が依存関係を逆転させるためにインターフェースを使用

主な相違点​

レイヤーアクセス:​

  • オニオン: レイヤーはより内側のレイヤーにのみアクセス可能
  • Prism: コア層は全レイヤーからアクセス可能で、オーケストレーション層が他のアクセスを仲介

アプリケーション層の役割:​

  • オニオン: アプリケーション層は主にインフラストラクチャへのインターフェースを定義
  • Prism: オーケストレーション層が全レイヤー間を積極的に調整

インフラストラクチャの分離:​

  • オニオン: ドメインからすべてのインフラストラクチャの関心事を分離することに焦点
  • Prism: GraphQLなど最新のインフラストラクチャ向けに特化したパターンを提供

実装パターン:​

  • オニオン: レイヤー内の実装パターンについてはあまり規定的ではない
  • Prism: インテントベースの通信や階層的プレゼンターなどの特定のパターンを定義

それぞれを選ぶタイミング​

オニオンアーキテクチャを選ぶとき:

  • インフラストラクチャの関心事からの最大限の分離が必要な場合
  • ドメインモデルが比較的安定している場合
  • 同じコンポーネントに対して複数のインフラストラクチャ実装がある場合

Prismを選ぶとき:

  • レイヤー実装パターンについてより多くのガイダンスが欲しい場合
  • GraphQLのような最新のインフラストラクチャ向けに最適化されたパターンが必要な場合
  • レイヤー間のより積極的な調整役が欲しい場合

ヘキサゴナルアーキテクチャ（ポートとアダプター）との比較​

Alistair Cockburnによって作成されたヘキサゴナルアーキテクチャは、ポートとアダプターを通じてアプリケーションコアを外部システムから分離します。

主な類似点​

  • コア分離: 両方ともコアアプリケーションロジックを保護
  • インターフェースベースの通信: 両方がレイヤー間の通信にインターフェースを使用
  • テスト容易性: 両方がテスト用に実装を簡単に入れ替え可能
  • 依存性の逆転: 両方がコアロジックを保護するために依存関係を逆転

主な相違点​

ポートの概念:​

  • ヘキサゴナル: すべての外部通信が明示的なポートを通過
  • Prism: コア層に直接アクセス可能で、他の通信は特定のパターンに従う

アダプターの実装:​

  • ヘキサゴナル: アダプターがポートと外部形式の間で変換
  • Prism: インフラストラクチャがコアインターフェースを直接実装

レイヤー編成:​

  • ヘキサゴナル: コアとアダプター以外に明示的なレイヤーは無し
  • Prism: 特定の責任を持つ明示的なレイヤー分離

UI通信:​

  • ヘキサゴナル: UIは独自のアダプターを持つ外部システムとして扱われる
  • Prism: 最新のUIフレームワーク向けに特化したプレゼンテーションパターン

それぞれを選ぶタイミング​

ヘキサゴナルアーキテクチャを選ぶとき:

  • 外部システムからの最大限の分離が必要な場合
  • 外部システムの実装を頻繁に入れ替える場合
  • 多様な外部統合が多数ある場合

Prismを選ぶとき:

  • コアアプリケーション内でより多くの構造が欲しい場合
  • GraphQLと最新のUIのための最適化されたパターンが必要な場合
  • 内部編成についてより多くのガイダンスが欲しい場合

ハイブリッドアプローチ​

実世界のアプリケーションの多くは、複数のアーキテクチャパターンの要素を組み合わせたハイブリッドアプローチを使用していることを覚えておく価値があります。Prism Architecture自体がこれらのパターンのいくつかからインスピレーションを得ています：

  • DDDから: リッチなドメインモデリングとビジネスコンセプトへの焦点
  • クリーン/オニオンから: レイヤー分離とコアロジックの保護
  • MVVM/Reduxから: UI状態管理とデータバインディングアプローチ（UIアーキテクチャ比較を参照）
  • ヘキサゴナルから: 外部システムとのインターフェースベースの通信

比較表要約​

側面Prism ArchitectureDDDクリーンオニオンヘキサゴナル
ドメイン重視高非常に高中高中
レイヤー分離バランス高非常に高高高
実装の複雑さ中高高中中
UIパターンガイダンス高低低低低
データアクセスの柔軟性高低中中中
GraphQL最適化高低低低中
学習曲線中急急中中
ボイラープレートコード中高高中中
テスト容易性高高非常に高高非常に高

正しい選択をする​

適切なアーキテクチャの選択は、特定のニーズによって異なります：

  • プロジェクトサイズ: 小規模なプロジェクトでは、よりシンプルなアーキテクチャまたはPrism Liteで十分かもしれません
  • チーム経験: チームの異なるアーキテクチャパターンに対する精通度を考慮
  • ドメインの複雑さ: より複雑なドメインは、よりドメイン重視のアーキテクチャから恩恵を受ける
  • UI要件: 最新の宣言的UIはPrismの特化したパターンから恩恵を受ける
  • APIテクノロジー: GraphQLベースのAPIはPrismの最適化されたパターンから恩恵を受ける
  • 長期メンテナンス: より構造化されたアプローチは長寿命アプリケーションで報われる

結論​

Prism Architectureは、GraphQLと宣言的UIを使用した最新のアプリケーション開発向けに最適化された、いくつかの確立されたパターンの実用的な進化を表しています。不必要なオーバーヘッドを削減しながらも、明確な関心の分離を維持し、レイヤードアーキテクチャの構造的メリットと実用的な実装の懸念事項のバランスを取っています。

すべての状況に完璧なアーキテクチャは存在しませんが、Prism Architectureは、ドメインの整合性と最新の実装効率のバランスを取る必要がある複雑なアプリケーションを構築するチームにとって、魅力的な選択肢を提供します。