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

よくある落とし穴

読了時間：約12分

はじめに​

Prismのような設計の優れたアーキテクチャでも、開発者は実装中に課題や落とし穴に遭遇することがよくあります。このドキュメントでは、Prismアーキテクチャを実装する際にチームが直面するよくある間違い、誤解、および課題と、それらを回避または克服するための実践的な戦略を紹介します。

これらの落とし穴を理解することで、チームは実装プロセスをより効果的に進め、手戻りを減らし、アーキテクチャの利点を十分に実現できます。これらの一般的な問題を事前に認識することで、Prismアーキテクチャをより成功裏に、そして遠回りすることなく実装できます。

レイヤー境界違反​

最もよくある落とし穴の一つは、Prismアーキテクチャの慎重に設計されたレイヤー境界が損なわれる場合に発生します。

アクセスすべきでないレイヤーへのアクセス​

落とし穴：依存関係ルールに従ってアクセスすべきでないレイヤーに直接アクセスすること。

症状：

  • 不適切なレイヤー境界を越えるインポート文
  • 独立しているべきレイヤー間の強い結合
  • 下位レイヤーの実装の置き換えが困難

防止策：

  • 可能な場合はプロジェクト構造を通じてコンパイラ強制を使用する
  • 依存関係が違反された場合に失敗するレイヤー境界テストを実装する
  • レイヤーの依存関係に焦点を当てた定期的なアーキテクチャレビューを実施する
  • 依存性注入を使用して依存関係を明示的かつ制御されたものにする

レイヤー間の循環依存関係​

落とし穴：レイヤー間の循環依存関係を作成することは、一方向の依存関係ルールに違反します。

症状：

  • 回避策を必要とするコンパイルの問題
  • 変更がシステム全体にどのように伝播するかを理解するのが難しい
  • レイヤー間の結合が増加する

防止策：

  • コア層に明確なインターフェースを定義する
  • プロジェクト構造を通じて一方向の依存関係を確保する
  • 循環依存関係を作成したくなった場合は、代わりにコアインターフェースを使用するようにリファクタリングする

通信パターンの誤用​

Prismアーキテクチャでは、効果的なレイヤー間通信のためにインテントとステートパターンを適切に使用することが不可欠です。

共通層の外部でインテントとステートを作成​

落とし穴：インテントとステートの型を共通層ではなく実装レイヤーで直接定義すること。

症状：

  • レイヤー間で一貫性のないインテントとステートの扱い
  • レイヤー間でオブジェクトを渡す際の型互換性の問題
  • 通信フローの追跡が困難
  • 類似の目的のための重複した定義

防止策：

  • すべてのインテントとステートの基本型を共通層で定義する
  • 目的と使用法によって明確なフォルダ構造で整理する
  • 実際のインスタンスは実行時に発信元のレイヤーで作成する
  • 適切な配置を確認するアーキテクチャ検証テストを実装する

不変性の原則に従わない​

落とし穴：可変のインテントとステートオブジェクトを作成すると、通信中に予期しない状態変更が発生する可能性があります。

症状：

  • 予測不可能なアプリケーションの振る舞い
  • レイヤー間のデータの不整合
  • 再現が難しいバグ
  • スレッドセーフティの問題

防止策：

  • すべてのインテントとステートクラスを不変に設計する
  • 既存のものを変更する代わりに新しいインスタンスを作成する
  • リストやマップには不変コレクションを使用する
  • 不変性を強制するためのlintルールや静的解析を実装する

レイヤー間の過剰な変換​

落とし穴：各レイヤー境界でデータを完全に変換し、不必要なマッピングのオーバーヘッドを作成すること。

症状：

  • マッピングのための過剰なボイラープレートコード
  • 不必要な変換によるパフォーマンスのボトルネック
  • マッパー間のコードの重複
  • 保守の負担の増加

防止策：

  • オブジェクトがアーキテクチャを通じて流れるパッケージ配信モデルに従う
  • 完全な変換ではなく、各レイヤーで必要なものだけを抽出する
  • 実際に必要な場合にのみ選択的マッピングを使用する
  • 適切な場合はステートオブジェクトに元のエンティティを含める

アーキテクチャの過剰設計​

適切なアーキテクチャは重要ですが、過剰な抽象化は逆効果になる可能性があります。

過剰なレイヤー化​

落とし穴：利益なしに複雑さを増す、あまりにも多くのレイヤーや過剰な抽象化を作成すること。

症状：

  • シンプルな機能でも多くのファイルにわたる変更が必要
  • 機能をどこに配置すべきか開発者が理解するのに苦労する
  • アーキテクチャのオーバーヘッドによる機能開発の遅延
  • 「アーキテクチャのためのアーキテクチャ」という考え方

防止策：

  • 必要なレイヤーから始め、必要に応じてのみ複雑さを追加する
  • 抽象化が具体的な利益をもたらしているかを定期的に評価する
  • 理論的な純粋さではなく実際の要件に導かれる
  • 小規模なアプリケーションにはPrism Liteの使用を検討する

早すぎる最適化​

落とし穴：実際のパフォーマンスニーズを理解する前にアーキテクチャコンポーネントを過度に最適化すること。

症状：

  • プロファイリング前に追加された複雑なキャッシングメカニズム
  • 早期に最適化されたカスタムコレクション型
  • クリーンな設計よりパフォーマンスの考慮事項が優先される
  • 重要でないパスの最適化に費やされる過剰な時間

防止策：

  • まずはクリーンで保守可能な設計に焦点を当てる
  • 最適化する前にパフォーマンスを測定する
  • 実際のボトルネックを特定した後にのみ最適化する
  • パフォーマンスが重要な領域に最適化を集中させる

ドメインモデルのアンチパターン​

コア層とドメイン層はPrismアーキテクチャの基盤を形成し、特別な注意が必要です。

貧血ドメインモデル​

落とし穴：行動を伴わないデータコンテナにすぎないエンティティクラスを作成すること。

症状：

  • ゲッターとセッターのみを持つエンティティ
  • エンティティではなくサービスにあるすべてのビジネスロジック
  • 単純なデータコンテナとして扱われるエンティティ
  • 排他的に一つのエンティティタイプと連携するサービス

防止策：

  • エンティティ固有の行動をエンティティに配置する
  • ビジネスメソッドを持つリッチなドメインモデルを設計する
  • 意味のあるドメイン概念には値オブジェクトを使用する
  • ドメインサービスは複数のエンティティにまたがる操作用に予約する

ドメインイベントの欠如​

落とし穴：重要なドメイン変更にドメインイベントを使用しないと、密結合につながります。

症状：

  • 通知のための直接的なサービス間呼び出し
  • あまりにも多くの責任を負うオーケストレーション層
  • リアクティブな振る舞いの実装が困難
  • ドメイン間の依存関係

防止策：

  • イベントを生成すべき重要なドメイン変更を特定する
  • 明示的なドメインイベント型を設計する
  • イベント発行と購読メカニズムを実装する
  • ドメイン境界を越えた変更の通信にイベントを使用する

インフラストラクチャ層の問題​

インフラストラクチャ層は、外部システムとの接続のために独自の課題を提示します。

インフラストラクチャの懸念の漏洩​

落とし穴：インフラストラクチャの詳細が上位レイヤーに漏れることを許可すること。

症状：

  • 永続化アノテーションを持つドメインモデル
  • レイヤーを通じて伝播するデータベース固有の例外
  • ドメインロジックで使用されるHTTPステータスコード
  • ドメインコード内のインフラストラクチャフレームワークへの参照

防止策：

  • コア層に明確なインターフェースを定義する
  • インフラストラクチャ固有のエラーをドメインエラーに変換する
  • インフラストラクチャの詳細をインフラストラクチャ層内に封じ込める
  • 外部通信にはデータ転送オブジェクトを使用する

リポジトリインターフェース契約の無視​

落とし穴：インターフェース契約に準拠しないリポジトリを実装すること。

症状：

  • 指定されたものと異なる結果を返すリポジトリ
  • インターフェースで文書化されていない副作用
  • 一貫性のない例外処理
  • 欠落したトランザクション管理

防止策：

  • リポジトリインターフェース契約を明確に文書化する
  • リポジトリ実装のための包括的なテストを実装する
  • 契約への準拠を検証するための統合テストを使用する
  • リポジトリ実装のための徹底的なコードレビューを実施する

プレゼンテーション層の間違い​

プレゼンテーション層はアプリケーションの最も目に見える部分であることが多く、独自の課題を提示します。

UIとドメインロジックの混在​

落とし穴：プレゼンテーションコンポーネントに直接ドメインロジックを埋め込むこと。

症状：

  • プレゼンターに実装されたビジネスルール
  • リポジトリを直接呼び出すプレゼンター
  • UIコンポーネント内のドメイン計算
  • 複数のプレゼンターにわたる重複したドメインロジック

防止策：

  • プレゼンターをUIロジックのみに集中させる
  • ビジネス操作をオーケストレーション層に委任する
  • ドメイン操作のための明確なユースケースを作成する
  • ドメインロジックから分離してプレゼンターをテストする

プレゼンター階層に従わない​

落とし穴：推奨される階層的アプローチではなく、フラットなプレゼンター構造を作成すること。

症状：

  • 無関係なプレゼンター間の直接的な依存関係
  • 細かすぎるロジックを含むトップレベルプレゼンター
  • オーケストレーション層を直接呼び出すコンポーネントプレゼンター
  • 不明確なプレゼンターの責任

防止策：

  • 3層プレゼンター階層（トップ、ミドル、コンポーネント）に従う
  • 各レベルの責任を尊重する
  • レベル間の適切な通信フローを確保する
  • 階層への準拠のためにプレゼンター設計をレビューする

UI状態の不変性を無視する​

落とし穴：可変のUI状態を使用することで、予測不可能なUI動作が生じる可能性があります。

症状：

  • 予期しないタイミングでのUI更新
  • コンポーネント間の状態の不整合
  • 再現が難しいUIバグ
  • UIスレッド上のスレッドセーフティの問題

防止策：

  • UI状態を不変として設計する
  • 変更のために新しい状態インスタンスを作成する
  • 適切な状態伝播メカニズムを使用する
  • 状態遷移を明示的にテストする

横断的な懸念事項​

いくつかの落とし穴は複数のアーキテクチャレイヤーにまたがり、包括的な解決策を必要とします。

不適切なエラー処理​

落とし穴：レイヤー間で一貫性のないまたは不適切なエラー処理。

症状：

  • ユーザーに公開される技術的エラー
  • レイヤー境界間の不適切なエラー変換
  • 重要なコンポーネントでの欠落したエラー処理
  • 一貫性のないエラーレスポンス形式

防止策：

  • 一貫したエラー処理戦略を設計する
  • レイヤー境界で適切にエラーを変換する
  • ビジネスエラーにはドメイン固有のエラータイプを使用する
  • 適切な場合はステートオブジェクトにエラー情報を含める

テスト可能性を無視する​

落とし穴：テストが困難または不可能な方法でコンポーネントを実装すること。

症状：

  • ハードコードされた依存関係を持つコンポーネント
  • グローバル状態に依存するロジック
  • テストフックのない時間依存の振る舞い
  • ビジネスロジックと密結合したUIコンポーネント

防止策：

  • 最初からテスト可能性を考慮して設計する
  • すべての依存関係に依存性注入を使用する
  • 時間、ランダム性、その他の外部要因のためのテストフックを提供する
  • 分離されたテストを可能にするために関心事を分離する

一貫性のない命名規則​

落とし穴：レイヤーやコンポーネント間で一貫性のない命名を使用すること。

症状：

  • レイヤー間で異なる命名スタイル
  • 類似の概念の一貫性のない命名
  • 名前に基づくコンポーネントの目的に関する混乱
  • 関連するコンポーネントを見つける困難さ

防止策：

  • 明確な命名規則を確立する
  • 一貫したプレフィックスとサフィックスを使用する
  • 命名規則ドキュメントで確立されたパターンに従う
  • コードレビュー中に命名レビューを実施する

高度な落とし穴​

これらのより微妙な落とし穴は、大規模なプロジェクトや進化するアプリケーションで現れる傾向があります。

過度に厳格な実装​

落とし穴：実践的なニーズよりもルールに焦点を当て、Prismアーキテクチャを過度に厳格に実装すること。

症状：

  • 生産性よりもアーキテクチャの純粋性が優先される
  • シンプルな機能に複雑な実装が必要
  • アーキテクチャの制約に対する開発者のフラストレーション
  • アーキテクチャのオーバーヘッドによる開発速度の低下

防止策：

  • アーキテクチャはアプリケーションに奉仕するものであり、その逆ではないことを覚えておく
  • アーキテクチャパターンの適用について実用的であること
  • アーキテクチャの整合性と開発効率のバランスを取る
  • パターンを特定のコンテキストに合わせて適用する

機能駆動型 vs レイヤー駆動型の組織​

落とし穴：機能組織とのバランスを取るのではなく、純粋にレイヤーによってコードを整理すること。

症状：

  • 機能に関連するすべてのファイルを見つけるのが困難
  • 機能の変更に多くのフォルダにわたる更新が必要
  • チーム組織とコード組織の不一致
  • 機能の所有権を割り当てる際の課題

防止策：

  • 大規模なアプリケーションには機能モジュールを検討する
  • レイヤーベースと機能ベースの組織のバランスを取る
  • 適切な場合はコード組織をチーム構造と一致させる
  • 最も意味のある場所で両方のアプローチを使用する

チーム構造の不一致​

落とし穴：アーキテクチャ境界と一致しないチーム構造。

症状：

  • チーム間の頻繁なマージ競合
  • 浸食されるアーキテクチャ境界
  • 一貫性のない実装パターン
  • アーキテクチャ境界を越えた意思決定の遅さ

防止策：

  • 可能な場合はチーム構造をアーキテクチャ境界と一致させる
  • アーキテクチャコンポーネントの明確な所有権を作成する
  • チーム間アーキテクチャガバナンスを確立する
  • すべてのチームにアーキテクチャガイダンスを提供する

実装チェックリスト​

よくある落とし穴を避けるため、Prismアーキテクチャの実装中にこのチェックリストを使用してください：

レイヤーセットアップ​

  • すべてのレイヤーに明確な境界と責任がある
  • 依存関係ルールが強制されている（コンパイル時または規約）
  • 共通層にすべてのインテントとステート定義が含まれる
  • コア層は外部依存関係を持たない

通信​

  • インテントとステートタイプが整理された構造に従っている
  • すべての通信オブジェクトが不変である
  • パッケージ配信モデルが一貫して使用されている
  • レイヤー間のデータとリクエストの明確なフロー

ドメインモデル​

  • エンティティはデータだけでなく行動も持っている
  • ドメイン概念には値オブジェクトが使用されている
  • ドメインサービスはエンティティ間の操作を処理する
  • 重要な出来事にはドメインイベントが使用されている

テスト​

  • 各レイヤーに適切なテストがある
  • コンポーネントはテスト可能性を考慮して設計されている
  • 統合テストがレイヤー間の相互作用を検証する
  • アーキテクチャ検証テストが境界を確認する

一般​

  • 命名規則が一貫して守られている
  • ドキュメントがアーキテクチャの決定を説明している
  • チームがアーキテクチャの原則を理解している
  • 定期的なアーキテクチャレビューが実施されている

結論​

Prismアーキテクチャを効果的に実装するには、これらのよくある落とし穴と、それらを回避するための積極的な戦略を認識する必要があります。これらの課題を事前に理解することで、チームは実装プロセスをより円滑に進め、アーキテクチャの完全な利点を実現できます。

Prismアーキテクチャは実用的で適応可能なように設計されていることを覚えておいてください。目標は完璧なアーキテクチャの純粋さではなく、効果的な開発を可能にするクリーンで保守可能なシステムです。詳細を特定のコンテキストに適応させながら、中核原則を正しく適用することに集中してください。

問題に遭遇した場合は、このガイドとPrismアーキテクチャの基本原則を参照してください。多くの場合、解決策はこれらの中核概念に立ち返り、状況に応じた適切な柔軟性をもって適用することにあります。