はじめに
この記事はソフトウェアアーキテクチャの基礎を勉強したシリーズの第2弾となります。
初回の基礎知識編はこちら
今回から各アーキテクチャスタイルごとに記事にまとめます
今回はレイヤードアーキテクチャです
レイヤードアーキテクチャとは
n層アーキテクチャとも知られており、最も一般的なアーキテクチャスタイルの一つである
実際にシステムを作る際にもユーザーインタフェースチーム、バックエンド開発チーム、データベース管理チームといった機能ごとにチームが編成されることがあるため、チーム編成ともマッチしており採用されやすい
しかし、暗黙のアーキテクチャアンチパターンや偶発的アーキテクチャアンチパターンといったアンチパターンにも該当する
トポロジー
一般的にはプレゼンテーション層、ビジネス層、永続化層、データベース層の4つのレイヤーで構成される。アプリケーションの規模によっては、3層になったり5層以上になったりする
デプロイ単位としては、プレゼンテーション層、ビジネス層、永続化層を1つにまとめて、データベース層を別のデプロイファイルとする方法もあるが、目的によってデプロイの組み合わせを変えていく
各レイヤーは特定の役割と責務があり、各層は特定のビジネス要求を満たすために必要な作業を抽象化している
これは関心ごとの分離を表現しており、各層が関連するロジックのみを扱うように範囲を限定することができる
技術によって分割されたアーキテクチャである
その一方で顧客ドメインが各層に散らばってしまうので、顧客ドメインに変更を加えるのが難しく、結果としてドメイン駆動設計のアプローチとは相性が悪い
層の分離
レイヤードアーキテクチャは閉鎖レイヤーと解放レイヤーの二つに分類できる
閉鎖レイヤーと解放レイヤーのどちらがいいかは、層の分離によって説明することができる
層の分離とはレイヤー間のコントラクトが変更されないように、どこかのレイヤー変更が他のレイヤーに影響を与えないようにするという考え方
仮にプレゼンテーション層が永続化層にアクセスできてしまうと、永続化層を変更するとビジネス層とプレゼンテーション層の2つに影響を与えてしまい、システムとして複雑になる
複雑ということは、変更が困難となり、高コストで脆くなる
層の分離を実現するためには閉鎖レイヤーである必要がある
閉鎖レイヤー
リクエストがレイヤーを上から下に移動していく際に、いずれのレイヤーもスキップできずひとつづつ層を経由するアーキテクチャー
解放レイヤー
層を無視してプレゼンテーション層がビジネス層を飛ばしてデータベース層にアクセスできるようなアーキテクチャー
レイヤーの追加
閉鎖レイヤーの方が影響範囲が小さく運用しやすいが、特定レイヤーのみ解放レイヤーとする方が理にかなっている場合がある
例えば、プレゼンテーション層がロジック層にある共有コンポーネント(ユーティリティクラス)を使用する場合は、共有コンポーネントを切り出してサービス層としてレイヤーに追加する
その際に閉鎖レイヤーだとロジック層が必ずサービス層を経由する必要があるが、解放レイヤーにしておけばロジック層はサービス層を飛ばして永続化層にアクセスすることができる
その他考慮事項
アーキテクチャシンクホールアンチパターン
ロジック層が処理するほどでもないような処理(基本的な顧客情報取得)は、アプリケーション層はリクエストをロジック層に渡し、ロジック層はリクエストをそのまま、下の層に渡す
つまり、ロジック層が何もせずにリクエストを渡しているだけになる
これをシンクホールという
シンクホールの割合が80%になっていたら、レイヤードアーキテクチャが最適なアーキテクチャスタイルではないことを示している指標となる
アーキテクチャの評価
- どのアーキテクチャスタイルが最適で判断がつかないときはレイヤードアーキテクチャは最適な出発点となる
- オブジェクト階層を浅くして、低輝度なモジュール性を維持することで別のアーキテクチャスタイルに移行しやすい
- 小規模でシンプルなアプリケーションやWebサイトに適している
- 予算や時間に厳しい条件においても適している
- アプリケーションの規模が大きくなると保守性、アジリティ、テスト容易性、デプロイ容易性といった特性に悪影響を及ぼす
| アーキテクチャ特性 | 評価 |
|---|---|
| 分割タイプ | 技術 |
| 量子数 | 1 |
| デプロイ容易性 | ★ |
| 弾力性 | ★ |
| 進化性 | ★ |
| 対障害性 | ★ |
| モジュール性 | ★ |
| 全体的なコスト | ★★★★★ |
| パフォーマンス | ★★ |
| 信頼性 | ★★★ |
| スケーラビリティ | ★ |
| シンプルさ | ★★★★★ |
| テスト容易性 | ★★ |
※★が多いほど評価が高い
自分なりの説明
ハンバーガー店のような、各担当がしっかり分業されているようなイメージ
プレゼンテーション層が永続化層にアクセスできてしまうと、現場は混乱しちゃう
- プレゼンテーション層 -> 客から注文を受ける。やり取りする
- ロジック層 -> ハンバーガーを実際に作る。パテとかを組み立てる
- 永続化層 -> レタスを切ったり、パテを焼いたりなどの、ハンバーガーを作るのに必要な食材の準備
- データベース層 -> 食材の仕入れや食材の保管をする
疑問点
- レイヤードアーキテクチャはドメイン駆動設計と相性が悪いはずなのに、「レイヤードアーキテクチャ」と検索するとDDDと出てくるのはなぜ?