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

ステートとインテント：Prismアーキテクチャにおける通信

読了時間：約15分

はじめに​

アーキテクチャレイヤー間の効果的な通信は、クリーンな境界を維持しながらデータと操作が自然に流れることを可能にするために不可欠です。Prismアーキテクチャは、インテントとステートオブジェクトに基づく「パッケージ配信」アプローチを使用し、適切なレイヤー分離を保ちながら一貫した効率的な通信メカニズムを作成します。

このドキュメントでは、ステートとインテントオブジェクトがPrismアーキテクチャの主要な通信メカニズムとしてどのように機能するか、どのように整理されるか、そしてレイヤー間でどのように流れるかを説明します。この通信モデルを理解することは、Prismアーキテクチャを成功裏に実装するための基礎となります。

コア通信概念​

パッケージ配信モデル​

Prismアーキテクチャでは、通信は郵便サービスに似たモデルに従います：

  • パッケージテンプレート：共通層の型定義（封筒のデザインのようなもの）
  • パッケージ：データを含むステートとインテントオブジェクト（封印された封筒のようなもの）
  • 仕分けセンター：パッケージを処理しルーティングするアーキテクチャレイヤー
  • 配送ルート：パッケージの移動方法を定義するレイヤー接続
  • 内容物：ステートとインテントオブジェクト内に運ばれるデータ

このモデルは、データとリクエストがアーキテクチャをどのように移動するかについて直感的な考え方を作り出します。

インテント：上向きの通信​

インテントはリクエストやアクションを表し、通常はアーキテクチャを上向きに流れます：

  • 目的：どのように起こるべきかではなく、何が起こるべきかを表現する
  • 方向：下位レイヤーから上位レイヤーへ上向きに流れる
  • 内容：必要なデータをすべて含む自己完結型オブジェクト
  • 処理：タイプに基づいて適切なレイヤーによって処理される

インテントは、組織階層を上る「サービスリクエスト」と考えてください。

ステート：下向きの通信​

ステートオブジェクトは現在の状態やデータを表し、通常は下向きに流れます：

  • 目的：現在の状態や操作結果を伝達する
  • 方向：上位レイヤーから下位レイヤーへ下向きに流れる
  • 内容：関連するすべての情報を持つ完全なデータパッケージ
  • 処理：各レイヤーがステートオブジェクトから必要なものを抽出する

ステートオブジェクトは、組織レベルを通じて下方に配布される「情報パケット」と考えてください。

不変性の原則​

Prismアーキテクチャのすべてのステートとインテントオブジェクトは不変です：

  • 一度作成されると、変更することはできない
  • 変更には新しいオブジェクトの作成が必要
  • アーキテクチャ全体でデータの整合性を確保する
  • 予期しない副作用を防ぐ

この不変性は、予測可能で追跡可能な通信パターンを作り出します。

共通層を定義ポイントとして​

すべてのインテントとステートの型は共通層で定義され、以下を提供します：

  • 通信インターフェースの単一の真実源
  • 定義を必要とするすべてのレイヤーへのアクセシビリティ
  • アーキテクチャ全体での一貫性
  • レイヤー間の依存関係違反の防止

このアプローチは、すべての通信タイプの定義を一か所に保ちながら、実際のインスタンスが実行時に適切なレイヤーで作成されることを可能にします。

インテントとステートの体系的構造​

共通層を整理するために、インテントとステートの定義は明確なフォルダ構造に従います：

各フォルダには関連するインテントまたはステートの型定義が含まれています：

  • Base/：コアインターフェースと抽象型
  • UI/：ユーザーインターフェースのアクションと表示に関連する型
  • Application/：アプリケーション操作に関連する型
  • Data/：データ操作に関連する型
  • Response/：操作レスポンスに関連する型

この編成は、通信タイプの検出性と保守性を向上させます。

インテントフローの例​

インテントは通常、ユーザーアクションやリクエストを表し、アーキテクチャを上向きに流れます：

各レイヤーはインテントを処理するか、または適切にコンテキストを追加して上向きに転送します。

ステートフローの例​

ステートオブジェクトは通常、操作結果や現在の状態を運び、下向きに流れます：

各レイヤーはステートオブジェクトから必要なものを抽出し、その特定のコンテキストに合わせて変換します。

レイヤー固有の実装​

プレゼンテーション層​

プレゼンテーション層はインテントオブジェクトを作成し、ステートオブジェクトを処理します：

プレゼンテーション層は主に：

  • ユーザーアクションからインテントオブジェクトを作成する
  • オーケストレーション層からのステートオブジェクトを処理する
  • 表示用にデータを抽出して変換する
  • ステートに基づいてUIを更新する

オーケストレーション層​

オーケストレーション層はプレゼンテーションからのインテントオブジェクトを処理し、ステートオブジェクトを作成します：

オーケストレーション層は主に：

  • プレゼンテーションからのインテントオブジェクトを処理する
  • ドメインとインフラストラクチャにわたる操作を調整する
  • ステートオブジェクトを作成または転送してプレゼンテーションに戻す
  • アプリケーションワークフローとプロセスを管理する

ドメイン層​

ドメイン層は通常、インテント/ステートオブジェクトではなくメソッド呼び出しで動作します：

ドメイン層は：

  • メソッド呼び出しを通じてビジネスロジックを実装する
  • エンティティと値オブジェクトを扱う
  • ドメインイベントを生成する場合がある
  • ドメインオブジェクトをオーケストレーション層に返す

インフラストラクチャ層​

インフラストラクチャ層はリクエストを処理し、ステートオブジェクトを作成します：

インフラストラクチャ層は：

  • オーケストレーション層からのリクエストを処理する
  • 外部システムとデータソースにアクセスする
  • レスポンス用のステートオブジェクトを作成する
  • 外部データをドメインオブジェクトに変換する

レイヤー間通信の例​

プレゼンテーション → オーケストレーション​

インフラストラクチャ → オーケストレーション​

包括的なフロー例​

この例では、関連するすべてのレイヤーを通じたインテントとステートの完全なフローを示しています：

これはアーキテクチャを流れるリクエストとレスポンスの完全なサイクルを示しています。

パッケージ配信アプローチの利点​

Prismアーキテクチャにおけるこの通信アプローチには、いくつかの主要な利点があります：

  1. クリーンなアーキテクチャ境界：レイヤー依存性違反なし
  2. 変換オーバーヘッドの削減：レイヤー間の最小限のデータ変換
  3. 明確なデータフロー：データがアプリケーション内をどのように移動するかを簡単に追跡可能
  4. 単一の真実源：すべての通信タイプが一つのレイヤーで定義
  5. 一貫性：すべてのレイヤー間通信に統一されたアプローチ
  6. 型安全性：レイヤー境界全体での強力な型付け
  7. 不変性の保証：アプリケーション全体でのデータ整合性

実装ガイドライン​

この通信アプローチを実装する際は：

  1. すべての型を共通層で定義：すべてのインテントとステートの型定義は共通層に属する
  2. 目的別に整理：意図された使用法によってフォルダ構造を使用して整理する
  3. 明確な命名：目的を示す説明的な名前を使用する（OrderIntent、ProductStateなど）
  4. 不変性：すべてのプロパティを読み取り専用にする
  5. 完全なパッケージ：各オブジェクトに必要なすべてのデータを含める
  6. 選択的アクセス：各レイヤーで関連するプロパティのみにアクセスする
  7. 最小限の変換：必要な場合にのみデータを変換する

避けるべき一般的なアンチパターン​

共通層外での型の作成​

問題：実装レイヤーでインテントまたはステート型を定義すると、一貫性がなくなり依存関係の問題が生じる。

解決策：すべてのインテントとステート型を常に共通層で定義する。

可変通信オブジェクト​

問題：可変なインテントまたはステートオブジェクトは、転送中に予期しない変更を引き起こす可能性がある。

解決策：すべてのインテントとステートオブジェクトを不変にする。

過剰な変換​

問題：各レイヤー境界でデータを完全に変換すると、不必要なオーバーヘッドが生じる。

解決策：各レイヤーが必要なものだけを抽出するパッケージ配信アプローチを使用する。

直接レイヤーアクセス​

問題：インテント/ステートパターンをバイパスして直接レイヤーにアクセスすると、アーキテクチャ境界に違反する。

解決策：レイヤー間の通信には常にインテントとステートオブジェクトを使用する。

結論​

Prismアーキテクチャにおけるステートとインテントへの「パッケージ配信」アプローチは、適切なアーキテクチャ境界を維持しながらレイヤー間のエレガントで効率的な通信メカニズムを提供します。すべての通信タイプを共通層で定義し、目的によって整理することで、データがアプリケーションを自然に流れることを可能にする一貫したシステムを作り出します。

このアプローチはアーキテクチャの純粋性と実践的な実装のバランスを取り、クリーンなレイヤー分離の利点を保ちながら不必要な変換オーバーヘッドを最小限に抑えます。これらのパターンに従うことで、ビジネスニーズをサポートしながら将来の進化に対して柔軟性を保つ、保守可能でスケーラブルなアプリケーションアーキテクチャを作成できます。