最近ソフトウェアアーキテクチャを勉強していて
各アーキテクチャについて順番に説明していきたいと思いますので、楽しみにしていただければ幸いです
今回はまず王道のアーキテクチャ、レイヤードアーキテクチャについてです
導入：最も一般的で基本的なアーキテクチャ
ソフトウェア開発の世界において、レイヤードアーキテクチャ（または「n層アーキテクチャ」）は、最も広く採用されているアーキテクチャスタイルの一つです
多くのアプリケーション、特に開発初期段階のプロジェクトにとって、このスタイルは事実上の標準となっています
その理由は、構造のシンプルさ、多くの開発者にとっての親しみやすさ、そして比較的低い開発コストにあります
これらの特長から、レイヤードアーキテクチャは多くの開発者に採用されてきました＠
このアーキテクチャは明確な設計意図なしに形成されることも少なくありません
開発チームが特定のアーキテクチャを意識せずに開発を進めた結果、自然とレイヤー構造が出来上がってしまうことがあるため、アンチパターンの「偶発的アーキテクチャ」の一例とも言えます
レイヤードアーキテクチャの基本構造
レイヤードアーキテクチャは、システムを構成するコンポーネントを、責務に応じて水平な「レイヤー（層）」として論理的に編成するアプローチです
この構造により、アプリケーション内の異なる関心事を明確に分離し、整理することができます。
各レイヤーの役割と責務
標準的なレイヤードアーキテクチャは、以下の4つの主要なレイヤーで構成されます
各レイヤーは、アプリケーション内で特定の役割と責務を担います。
- プレゼンテーション層
ユーザーインターフェイス（UI）の表示と、バックエンドとの通信ロジックを担当
ユーザーからの入力を受け付け、その結果を表示する責務を持ちます - ビジネス層
アプリケーションの核心的なビジネスロジックやビジネスルールを実行
プレゼンテーション層からのリクエストに基づき、特定の業務処理を行います - 永続化層
データベースとのデータのやり取り（読み書き）を担当します
SQLクエリの実行やオブジェクトリレーショナルマッピング（ORM）の管理などがこの層の責務です
小規模なアプリケーションでは、ビジネス層に統合されることもあります。 - データベース層
アプリケーションのデータを物理的に保管する場所です
通常、リレーショナルデータベースやファイルシステムがこの層に該当します。
関心の分離と技術による分割
レイヤードアーキテクチャの重要な設計思想の一つに「関心の分離」があります
各レイヤーが特定の責務に特化することで、開発者は自身の専門領域（例：UI開発、データベース管理）に集中でき、アーキテクチャ全体の見通しが良くなります
このアーキテクチャは、コードをビジネスドメイン（例：「顧客管理」や「注文処理」）ごとではなく、技術的な役割（例：「プレゼンテーション」や「永続化」）で分割する「技術による分割」という特徴を持ちます
つまり、論理的には単一のビジネスコンセプトに集中している変更が、すべての技術レイヤーにわたる修正を要求することがあります
例えば、「顧客ステータス」機能を追加したい時
データベーススキーマの変更（データベース層）、 データアクセスオブジェクトの修正（永続化層）、ステータス計算ルールの実装（ビジネス層）、そしてそれを表示するUIコンポーネントの改修（プレゼンテーション層）が必要になります
この修正範囲の大きさは、このアーキテクチャスタイルの決定的な制約です
層の分離
レイヤードアーキテクチャの健全性を保ち、その変更容易性や保守性を最大限に引き出すためには、「層の分離」という概念を理解することが不可欠です
これは、各レイヤーが他のレイヤーの内部実装に依存せず、独立して機能できるようにするための重要なルールです
閉鎖レイヤーと開放レイヤー
層の分離を実現するために、各レイヤーは「閉鎖レイヤー」または「開放レイヤー」として定義されます
- 閉鎖レイヤー
リクエストは、いかなるレイヤーもスキップすることなく、必ず直下の層を経由しなければならないという厳格なルールです
セキュリティの高いビルで、各チェックポイント（層）を順番に通過しなければならないようなものだと考えてください
ロビーから最上階へ直接エレベーターで行くことは許されません。 - 開放レイヤー
特定の状況下で、直下のレイヤーをバイパス（スキップ）することが許されるルールです
これは、効率化のために特定のフロアを迂回できる高速エレベーターのようなものです
ただその利用はセキュリティやロジスティクスの問題を避けるために慎重に管理されなければなりません
なぜ「層の分離」が重要なのか
レイヤーを原則として「閉鎖」にするという戦略的な判断は、保守性の高いシステムを構築するための基礎的な実践です
もし、プレゼンテーション層がビジネス層を飛ばして直接データベースにアクセスできるような設計を許してしまうと、何が起こるのか
それは、変更の影響範囲が膨大に広がり、密結合で脆弱なシステムが生まれます
例えば、データベースのスキーマを変更した場合、その影響は永続化層だけでなく、ビジネス層やプレゼンテーション層にも波及してしまいます
「層の分離」を徹底することで、各レイヤーは独立したコンポーネントとして機能し、他のレイヤーの内部実装を知ることなく連携できます
これにより、特定のレイヤーの変更が他のレイヤーに影響を与えることを防ぎ、アーキテクチャ全体の保守性と再利用性を高めることができるのです
新しいレイヤーの追加
アプリケーションの成長に伴い、既存のレイヤー構造では対応しきれない共通機能が必要になることがあります
共通のドメイン機能を管理するために、新しい「サービス層」を追加するアプローチが有効です
この新しいサービス層をプレゼンテーション層とビジネス層の間に配置します。
ここで重要なのは、この新しいサービス層を「開放レイヤー」として設計することです
これにより、プレゼンテーション層は共通サービスにアクセスでき、一方でビジネス層は、必要に応じてこのサービス層をバイパスして（飛ばして）、直接永続化層にアクセスする柔軟性を保つことができます
このアプローチにより、アーキテクチャのルールを維持しつつ、システムの拡張性を確保することが可能になります
「アーキテクチャシンクホール」アンチパターン
レイヤードアーキテクチャで頻繁に見られるアンチパターンの一つに「アーキテクチャシンクホール」があります
これは、リクエストがあるレイヤーを通過する際に、何一つビジネスロジックを実行することなく、ただ下の層へ受け流されるだけの状態を指します
例えば、単純なデータ取得リクエストが、プレゼンテーション層からビジネス層、永続化層へと、各層で意味のある処理を伴わずにそのまま通過していくケースです
この現象は、不必要なオブジェクトのインスタンス化やメソッド呼び出しといったオーバーヘッドを生み、アプリケーションのパフォーマンスに悪影響を与えます
ソフトウェアアーキテクチャの健全性を測る診断基準の一つに、「80対20ルール」というものがあります
これはリクエストの80%が、あるレイヤーを意味のあるロジックを実行することなく通過しているなら、それはそのレイヤーが価値ではなく「形式的なオーバーヘッド」を追加している強力なシグナルになるというものです
つまり、データの加工も、バリデーションも、計算もせず、ただ「右から左へ」データを受け渡しているだけの処理が全体の8割を占める場合、そのレイヤー構造は過剰設計です
レイヤードアーキテクチャの評価
主な利点
レイヤードアーキテクチャは、特に以下のような状況において最適な選択肢となり得ます。
- シンプルさと親しみやすさ
構造が直感的で理解しやすく、多くの開発者にとって馴染み深いため、学習コストが低く、チームへの導入が容易です - 開発コストの低さ
小規模でシンプルなアプリケーションやWebサイトの開発に適しており、迅速に開発を始めることができます
実績のあるパターンであるため、関連するツールやドキュメントも豊富です - 優れた出発点
厳しい予算や時間の制約があるプロジェクト、または将来的なアーキテクチャがまだ不透明なプロジェクトの初期段階において、堅実な基盤を提供します
まずこのスタイルで開発を始め、必要に応じて他のスタイルへ移行するという戦略も有効です
主な欠点
-
デプロイ・テスト容易性の低さ
モノリシックな構造ゆえに、わずかな変更であってもアプリケーション全体の再構築・再テスト・再デプロイが必須となります
これはリリースのリスクと手間を増やし、迅速なデプロイサイクルを阻害する要因となります -
スケーラビリティ・弾力性の欠如
アプリケーション全体が「単一のユニット」として動作するため、負荷の高い特定の機能だけを独立してスケールさせることが極めて困難になります
そのため、トラフィックの変動に対する柔軟性に欠けるといえるでしょう -
耐障害性の脆弱さ
メモリリークなどの障害が一箇所で発生すると、アプリケーション全体がクラッシュする恐れがあります
また、復旧にはシステム全体の再起動が必要となるため、平均回復時間（MTTR）も長くなる傾向があります -
パフォーマンスの懸念
何も処理せず通過するだけの層（アーキテクチャ・シンクホール）によるオーバーヘッドや、並列処理の不足により、本質的に高性能が求められるシステムには不向きです
高い性能を実現するには、追加の設計努力が必要になります
結論
レイヤードアーキテクチャは、その明快な構造とシンプルさから、ソフトウェア開発を始めた人にとって、非常に重要な学習の出発点となります
関心の分離やコンポーネント化といった基本的な設計原則を学ぶ上で、これほど適したスタイルは他にないかと思います
ここで重要なのは、このアーキテクチャが持つ限界を正しく理解することです
プロジェクトが成長し、スケーラビリティやデプロイの俊敏性が求められるようになると、モノリシックな構造が足かせとなることがあります
その際には、サービスベースアーキテクチャやマイクロサービスといった、より高度なアーキテクチャスタイルへの移行を検討する将来的な視点が必要です
レイヤードアーキテクチャはアーキテクト学習における、より複雑で要求の厳しいシステムを設計するための揺るぎない基礎を築くための出発点なのです
ここまで読んでいただきありがとうございました！！！