architecture-paradigm-layered

レイヤード（N-Tier）アーキテクチャパラダイム

このパラダイムを採用する場合

• 中規模システムで、チームが明確なアーキテクチャ上の境界と、なじみのある構造を必要とするとき。
• コンプライアンスチームや運用チームが、関心事の明確な分離（例：UI とドメインロジック、永続化）を必要とするとき。
• デプロイ成果物はモノリスのままでも、コードの明瞭さや分離が損なわれているとき。

このパラダイムを採用しない場合

• 高いスケーラビリティが求められ、コンポーネントを個別にスケーリングする必要があるとき
• 複数のチームが独立したデプロイサイクルを必要とするとき
• 複雑なビジネスロジックにより、レイヤー間の通信が頻繁に必要となるとき
• マイクロサービスアーキテクチャがすでに計画されている、または導入されているとき
• リアルタイム処理の要件により、レイヤー間の通信が遅すぎるとき

導入手順

1. レイヤーを定義する：明確なレイヤーのセットを定めます。一般的な構成は、Presentation -> Application/Service -> Domain -> Data Access です。
2. 依存関係の方向を徹底する：特定のレイヤーのコードは、その直下のレイヤーにのみ依存できます。「上向き」の依存関係やインポートは禁止します。
3. 横断的関心事を一元化する：ロギング、認証、バリデーションなどの関心事は、各レイヤーでロジックを重複させず、一元化されたミドルウェアやポリシーとして実装します。
4. 各レイヤーに適したテストを行う：ドメインレイヤーの単体テスト、オーケストレーションロジックのサービスレイヤーテスト、永続化アダプターの統合テストなど、各レイヤーに適したテスト戦略を適用します。
5. レイヤー間の連携を文書化し、徹底する：依存関係図を最新の状態に保ち、自動化されたアーキテクチャテストを使って、レイヤー化のルールに反する「近道」の依存関係を開発者が作成できないようにします。

主な成果物

• 各レイヤーの責務、レイヤー間で許可される依存関係、および例外に関するポリシーを記録したアーキテクチャ決定記録（ADR）。
• プロジェクトのドキュメントとともに保管される正式な依存関係図。
• ルール違反をマージ前に防ぐ、自動化されたアーキテクチャチェック（例：ArchUnit、dep-cruise、またはカスタムスクリプトの使用）。

技術ガイダンス

レイヤーの実装パターン：

• プレゼンテーションレイヤー：React/Vue/Angular（フロントエンド）、MVC コントローラー（バックエンド）
• アプリケーションレイヤー：サービスクラス、アプリケーションサービス、ユースケースオーケストレーター
• ドメインレイヤー：ビジネスエンティティ、ドメインサービス、ビジネスルールのバリデーション
• データアクセスレイヤー：リポジトリパターン、ORM マッパー、データアクセスオブジェクト（DAO）

アーキテクチャの徹底に使うツール：

• Java：依存関係ルールのテストに ArchUnit
• JavaScript/TypeScript：依存関係の追跡を含む ESLint ルール
• C#：アーキテクチャ分析に NDepend
• Python：カスタムデコレーターとインポート分析ツール

一般的なレイヤー構成：

• 3 レイヤー：プレゼンテーション → ビジネスロジック → データアクセス
• 4 レイヤー：プレゼンテーション → アプリケーション → ドメイン → インフラストラクチャ
• 5 レイヤー：UI → コントローラー → サービス → ドメイン → 永続化

実例

エンタープライズ ERP システム：SAP や Oracle ERP は、レイヤードアーキテクチャを使用してユーザーインターフェースをビジネスロジックやデータベース操作から分離し、異なるフロントエンドアプリケーションで同じビジネスルールを共有できるようにしています。

銀行アプリケーション：金融機関は、規制要件への準拠のため、顧客向けインターフェース、トランザクション処理、安全なデータ保存を厳密に分離する目的で、レイヤードアーキテクチャを採用しています。

E コマースプラットフォーム：従来型の E コマースサイトは、商品カタログ、ショッピングカートのロジック、注文処理、決済処理をそれぞれ別のレイヤーに分けるために、レイヤードアーキテクチャを使用しています。

リスクと軽減策

• 過度な硬直性とレイテンシ：
  • 軽減策：複数のレイヤーにまたがる機能では、厳密に従うことで過剰な「パススルー」コードが発生し、レイテンシが増加する場合があります。そのような場合は、適切にファサードパターンを使用して、より直接的なインターフェースを提供することを検討してください。
• 「漏れのある」レイヤー：
  • 軽減策：開発者は効率を優先してアーキテクチャ上のルールを迂回したくなることがありますが、これはアーキテクチャを損ないます。アーキテクチャ上の違反はすべて、ビルドを失敗させるか、コードレビューで重大な問題として扱ってください。

具体的なコンポーネント

このパラダイムの実装で使われる傾向のある、ツールや抽象化の用語です。依存関係ではなく、tools: フロントマターでもありません。

• dependency-validator：レイヤーが許可された深さを超えてインポートした場合にビルドを失敗させます
• layer-enforcer：名前空間がレイヤーのルールに適合しているかを確認する静的解析ゲートです
• architecture-compliance-checker：実装されたレイヤーグラフと文書化されたレイヤーグラフの差分を確認します

完了基準

• ADR に、選択したレイヤースタック（3層、4層、または5層）、各レイヤーの責務、依存関係の許可される方向、およびレイヤー間の例外に関するポリシーが記載されています。
• 正式な依存関係図がプロジェクトのドキュメントにコミットされ、ADR に記載されたレイヤー境界と一致しています。
• 自動アーキテクチャチェック（ArchUnit、dep-cruise、または同等のもの）が CI に組み込まれ、上位レイヤーへの依存関係がある場合にビルドを失敗させます。
• 横断的関心事（ログ記録、認証、検証）はミドルウェアまたはポリシーとして一度だけ実装され、各レイヤーの実装間で重複していません。