レイヤーごとのセットアップ
読了時間:約15分
はじめに
Prismアーキテクチャの各レイヤーをセットアップするには、責任、依存関係、および実装パターンを慎重に検討する必要があります。このドキュメントでは、コア層からプレゼンテーション層まで、クリーンな境界を作りながらデータと操作の自然な流れを可能にすることに焦点を当て、各レイヤーを実装するための実践的なガイドを提供します。
各レイヤーを正しくセットアップする方法を理解することは、Prismアーキテクチャの利点を実現するために不可欠です。これらのガイドラインに従うことで、モジュール化され、保守可能で、アーキテクチャの中核原則に沿ったコードベースを作成することができます。
一般的なセットアップの考慮事項
個々のレイヤーに入る前に、全体的なセットアップに適用されるいくつかの横断的な考慮事項があります:
依存関係の方向
Prismアーキテクチャでは、依存関係は一般的に内側に流れることを覚えておいてください:
- コア層は依存関係を持たない(標準ライブラリを除く)
- ドメイン層はコアのみに依存する
- オーケストレーション層はコア、ドメイン、インフラストラクチャ、および共通層に依存する
- インフラストラクチャ層はコアと共通層に依存する
- プレゼンテーション層はコア、オーケストレーション、および共通層に依存する
- 共通層はコアのみに依存する
明確な境界
次のものを使用して、レイヤー間に明確な境界を確立します:
- 明示的なインターフェース(プロトコル)
- アクセス修飾子(public、internal、private)
- プロジェクト/パッケージ構造(マルチパッケージアプローチを使用する場合)
- 一貫した依存性注入
- レイヤー固有のテストとモック
通信メカニズム
Prismアーキテクチャでは、レイヤー間の通信にパッケージ配信モデルを使用します:
すべてのインテントとステートタイプの定義は共通層に存在し、実際のインスタンスは実行時に発信元のレイヤーで作成されます。
共通層のセットアップ
共通層はPrismアーキテクチャの重要な部分であり、レイヤー間で流れるすべての通信タイプの定義を提供します。
実装すべき主要コンポーネント
-
インテントとステートの基本タイプ:
- インテントとステートオブジェクトの基本インターフェースを設定
- タイプを明確なフォルダ構造で整理
- より良い整理のためにレイヤー固有のサブフォルダを作成
-
データ転送オブジェクト(DTO):
- データ交換のためのシリアル化可能なオブジェクトを作成
- 異なるコンテキスト用の異なるDTOを実装
- 一貫した変換のためのマッピング可能なインターフェースを追加
-
表示オブジェクト(DO):
- UI対応のデータ構造を設計
- フォーマット済み、ローカライズされたデータを含める
- 異なるUIコンテキスト用の目的固有の表示オブジェクトを作成
-
ユーティリティ:
- フォーマットユーティリティを開発
- バリデーションヘルパーを作成
- 共通アルゴリズムを実装
- エラー処理ユーティリティを追加
インテントとステートの整理された構造
フォルダ構成:
- Base/:コアインターフェースと抽象型
- UI/:ユーザーインターフェースアクションと表示に関連する型
- Application/:アプリケーション操作に関連する型
- Data/:データ操作に関連する型
- Response/:操作レスポンスに関連する型
実装アプローチ
共通層は以下に焦点を当てて実装する必要があります:
- レイヤー間通信のための明確な型定義
- 目的とレイヤー使用による編成
- フレームワークからの独立性
- データオブジェクトの不変性
- すべての通信タイプにわたる一貫性
共通層の主要な実装のヒント
- 整理された構造:インテントとステートタイプのフォルダ編成パターンに従う
- 目的に特化した型:汎用的なものではなく、特定のユースケース向けの異なる型を作成する
- 不変性:すべてのDTOと通信オブジェクトを不変に設計する
- フレームワークからの独立性:共通層をUIやインフラストラクチャフレームワークから自由に保つ
- クリーンな責任:各ユーティリティは単一の明確な責任を持つべき
- 命名規則:すべての型に明確で一貫した命名を使用する
- ドキュメント:各型の目的と使用法を明確に文書化する
コア層のセットアップ
コア層はPrismアーキテクチャアプリケーションの基盤を形成し、ドメインエンティティ、値オブジェクト、およびコアプロトコルを含みます。
実装すべき主要コンポーネント
-
ベースエンティティと値オブジェクトのプロトコル:
- ドメインオブジェクトの基礎となるインターフェースを確立
- アイデンティティと等価性の要件を定義
- 必要に応じてシリアル化機能を設定
-
値オブジェクト:
- 重要なドメイン概念のための不変タイプを作成
- ドメイン固有の操作を実装
- エンティティ識別子に値オブジェクトを使用
- 自己検証ロジックを含める
-
エンティティ:
- アイデンティティを持つコアビジネスオブジェクトを定義
- 可変性アプローチを決定(不変 vs 制御された可変性)
- エンティティ固有の検証を含める
- ビジネスメソッドを実装
-
コアプロトコル:
- リポジトリインターフェースを定義
- サービス契約を確立
- ファクトリインターフェースを作成
- ドメインイベントインターフェースを設定
実装アプローチ
コア層は以下に焦点を当てて実装する必要があります:
- 技術的な懸念よりもドメインの正確さ
- 意味のある操作を持つリッチなドメインモデル
- 強力な型付けとドメイン固有の型
- 他のレイヤーが実装するための明確なインターフェース
- フレームワークや外部依存関係からの独立性
コア層の構造
コア層の主要な実装のヒント
- 純粋に保つ:コア層は外部依存関係やフレームワークから自由であるべき
- 不変性:予期しない状態変化を防ぐために、不変なエンティティと値オブジェクトを好む
- リッチなドメインモデル:データだけでなく、エンティティに意味のあるビジネスメソッドを含める
- 型安全性:プリミティブではなく、IDやその他の重要な概念にカスタム型を使用する
- 検証:エンティティと値オブジェクトの初期化に基本的な検証を含める
- 明確なインターフェース:他のレイヤーが実装する明確で簡潔なプロトコルを定義する
ドメイン層のセットアップ
ドメイン層には、コアビジネス操作を実装するビジネスロジック、検証ルール、およびドメインサービスが含まれています。
実装すべき主要コンポーネント
-
ドメインサービス:
- 単一のエンティティに属さないビジネス操作を実装
- エンティティ間プロセスのためのサービスを作成
- 計算とビジネスルールサービスを開発
-
バリデーションサービス:
- 複雑なルールのための包括的な検証を構築
- 検証結果構造を作成
- コンテキスト固有の検証ロジックを実装
-
ルールサービス:
- 動的なビジネスルール用のサービスを開発
- ポリシー実施メカニズムを実装
- ルール評価サービスを作成
-
ドメインイベント:
- 重要なドメインの発生のためのイベントタイプを設計
- イベント発行メカニズムを作成
- イベント関連インターフェースを実装
ドメイン層の構造
実装アプローチ
ドメイン層は以下に焦点を当てて実装する必要があります:
- 純粋なビジネスロジック
- リッチで表現力のあるドメイン操作
- 包括的な検証
- ビジネスルールの強制
- ドメインイベントの生成
ドメイン層の主要な実装のヒント
- 純粋なビジネスロジック:ドメインサービスをインフラストラクチャの懸念なしにビジネスルールに集中させる
- 不変性:予期せぬ状態変化を防ぐために不変性を設計する
- リッチな検証:ビジネスルールをキャプチャする包括的な検証を実装する
- 意味のあるエラー:ビジネスルール違反を明確に伝えるドメイン固有のエラータイプを作成する
- サービスの構成:サービスを構成可能で再利用可能に設計する
- テスト:明確な入力と出力を持つドメインサービスを高度にテスト可能にする
インフラストラクチャ層のセットアップ
インフラストラクチャ層はデータアクセス、外部サービス統合、および技術的な懸念を扱います。
実装すべき主要コンポーネント
-
リポジトリ:
- コア層のリポジトリインターフェースを実装
- データソース抽象化を作成
- キャッシングメカニズムを開発
- トランザクション処理を構築
-
APIクライアント:
- HTTP/ネットワーククライアントを開発
- APIエンドポイント管理を作成
- 認証処理を実装
- リクエスト/レスポンス処理を構築
-
クエリサービス:
- 最適化されたデータアクセスサービスを作成
- GraphQL固有のクエリ処理を実装
- 複雑なクエリビルダーを開発
- 効率的なデータローダーを構築
-
システムサービス:
- デバイス/プラットフォーム機能を実装
- ファイルシステムサービスを作成
- ロギングメカニズムを開発
- 構成サービスを構築
インフラストラクチャ層の通信
実装アプローチ
インフラストラクチャ層は以下に焦点を当てて実装する必要があります:
- 技術的機能へのクリーンなインターフェース
- 外部依存関係の抽象化
- 効率的なデータアクセス
- エラー処理と回復力
- パフォーマンス最適化
- 共通層の定義を使用したステートオブジェクトの作成
インフラストラクチャ層の主要な実装のヒント
- インターフェースの遵守:コア層で定義されたインターフェースを厳密に実装する
- エラー変換:技術的エラーをドメインに意味のあるエラーに変換する
- キャッシング戦略:パフォーマンス最適化のための適切なキャッシングを実装する
- 回復力パターン:リトライロジック、サーキットブレーカー、その他の回復力パターンを追加する
- テスト可能性:外部依存関係のためのテストダブルを作成する
- ステート作成:レスポンスオブジェクトを作成する際に共通層のステート定義を使用する
オーケストレーション層のセットアップ
オーケストレーション層は他のすべてのレイヤー間の操作を調整し、アプリケーションフローとトランザクションを管理します。
実装すべき主要コンポーネント
-
ユースケース:
- 原子的なエンティティ中心の操作を作成
- 単一責任の操作を実装
- 入力検証とエラー処理を開発
- 結果フォーマットを構築
-
オーケストレーションサービス:
- 機能領域の調整を実装
- 複数ユースケースの操作を作成
- 機能固有の状態管理を開発
- サービス構成を構築
-
ワークフローコーディネーター:
- 複雑な複数ステッププロセス管理を作成
- クロスドメイン調整を実装
- プロセスフロー用の状態マシンを開発
- 分散操作用のSAGAパターンを構築
-
イベントハンドラー:
- ドメインイベントサブスクライバーを実装
- イベント駆動ワークフローを作成
- イベント記録と監査を開発
- イベントベースの通知を構築
オーケストレーション層の通信フロー
実装アプローチ
オーケストレーション層は以下に焦点を当てて実装する必要があります:
- 明確なフロー調整
- 他のレイヤーへの適切な委任
- トランザクション管理
- エラー処理と復旧
- 階層的な組織
- プレゼンテーション層からのインテント処理
- 共通層の定義を使用したステート作成
オーケストレーション層の主要な実装のヒント
- 単一責任:各ユースケースは明確で集中した目的を持つべき
- 適切な委任:ドメインロジックはドメイン層に、データアクセスはインフラストラクチャに委任する
- エラー処理:包括的なエラー処理と復旧戦略を実装する
- トランザクションの整合性:操作がデータの一貫性を維持することを確保する
- 明確なインターフェース:プレゼンテーション層に明確で定義されたインターフェースを提供する
- インテント処理:プレゼンテーション層からのインテント処理を設計する
- ステート作成:レスポンスオブジェクトを作成する際に共通層のステート定義を使用する
プレゼンテーション層のセットアップ
プレゼンテーション層はユーザーインターフェースを管理し、ユーザー入力をキャプチャし、アプリケーションデータをユーザーフレンドリーな形式で表示します。
実装すべき主要コンポーネント
-
プレゼンター/ビューモデル:
- 階層的なプレゼンター構造を作成(PrismUI)
- UIロジックと状態管理を実装
- インテント処理を開発
- ステート変換を構築
-
UI状態管理:
- 不変な状態構造を作成
- 状態伝搬を実装
- 状態派生を開発
- 状態差分計算を構築
-
インテントシステム:
- ユーザーアクション用のインテントオブジェクトを作成
- インテントバブリングを実装
- インテントハンドラーを開発
- インテントのユースケースへの変換を構築
-
ナビゲーション管理:
- 画面ナビゲーションを実装
- ディープリンクサポートを作成
- ナビゲーション状態管理を開発
- モーダルとダイアログの調整を構築
プレゼンテーション層の通信フロー
実装アプローチ
プレゼンテーション層は以下に焦点を当てて実装する必要があります:
- ビューからの明確なUIロジックの分離
- 階層的コンポーネント編成
- 単方向データフロー
- 予測可能な状態管理
- 共通層の定義を使用したインテントの作成
- オーケストレーション層からのステートオブジェクトの処理
プレゼンテーション層の主要な実装のヒント
- 階層的編成:PrismUIの3層プレゼンター階層に従う
- ビューからの分離:プレゼンターをビュー実装の詳細から独立させる
- 不変状態:予測可能なUI更新のために不変状態オブジェクトを使用する
- インテントベースの通信:ユーザーアクションに明示的なインテントを使用する
- 単方向フロー:下向きの状態、上向きのインテントというフローパターンを維持する
- インテント作成:インテントオブジェクトを作成する際に共通層のインテント定義を使用する
- ステート処理:オーケストレーション層から受け取ったステートオブジェクトを処理する
実装シーケンス
Prismアーキテクチャをセットアップする際、次の推奨シーケンスに従ってください:
-
共通層から始める:
- インテントとステートのベースタイプを定義
- 組織構造を設定
- 初期DTOとDOを作成
-
コア層を設定する:
- 主要なエンティティと値オブジェクトを定義
- コアプロトコルを確立
- ドメイン語彙を作成
-
ドメイン層を実装する:
- ドメインサービスを作成
- バリデーションロジックを構築
- ビジネスルールを実装
-
インフラストラクチャ層を追加する:
- リポジトリインターフェースを実装
- APIクライアントを作成
- システムサービスを開発
-
オーケストレーション層を開発する:
- ユースケースを作成
- オーケストレーションサービスを構築
- ワークフローを実装
-
最後に、プレゼンテーション層を構築する:
- プレゼンター階層を実装
- 状態管理を作成
- インテントシステムを開発
このシーケンスにより、各レイヤーが前のレイヤーからの堅固な基盤の上に構築されることが保証されます。
共通レイヤーのセットアップの課題
課題1:レイヤー境界の維持
問題:レイヤーが依存関係ルールに違反する方法で互いにアクセスすること。
解決策:
- 可能な場合はプロジェクト構造を通じてコンパイラ強制を使用
- レイヤー境界テストを実装
- 定期的なアーキテクチャレビューを実施
- 依存関係を明示的にするために依存性注入を使用
課題2:過剰設計
問題:不必要な抽象化を導入する過度に複雑な構造を作成すること。
解決策:
- シンプルに始め、必要に応じて進化させる
- まずビジネス要件に集中
- 必要な場合にのみ抽象化を導入
- 簡素化するために定期的にリファクタリングする
課題3:データ変換オーバーヘッド
問題:レイヤー間で異なるデータモデル間の過度のマッピング。
解決策:
- 適切な場合はコア層エンティティを全体的に使用
- 汎用的なものではなく目的特化DTOを作成
- 効率的なマッピングユーティリティを実装
- パフォーマンスクリティカルなパスを慎重に検討
課題4:不完全なレイヤー実装
問題:適切なアーキテクチャ機能に必要な主要コンポーネントがレイヤーに欠けていること。
解決策:
- レイヤー実装用のチェックリストを使用
- アーキテクチャ検証テストを作成
- レイヤーの責任を明確に文書化
- アーキテクチャコンプライアンスのためのピアレビューを実施
結論
Prismアーキテクチャの各レイヤーをセットアップするには、責任、依存関係、および通信パターンの慎重な計画と注意が必要です。このドキュメントのガイドラインに従うことで、Prismアーキテクチャの利点を実現するクリーンで保守可能な実装を作成することができます。
Prismアーキテクチャは独断的というよりも実用的であるように設計されていることを覚えておいてください。これらのガイドラインを特定のプロジェクトニーズに適応させながら、関心事の分離、依存関係ルール、およびインテントベースの通信という中核原則を維持します。
成功した実装の鍵は一貫性と明確さです。チームのための明確な規約を確立し、アプローチを文書化し、すべてのチームメンバーが使用されているアーキテクチャパターンを理解していることを確認します。