こんにちは、Tochiです。 ソフトアーキテクチャの基礎10章の振り返りをアウトプットしてきます。
10章 レイヤードアーキテクチャ
レイヤードアーキテクチャ
レイヤードアーキテクチャはn層アーキテクチャと呼ばれ最も一般的なアーキテクチャスタイル。 システム設計する組織にとっては、コンウェイの法則が働くため各層がUI開発チームやバックエンドチームなどにうまくフィットしている。
そのため、レイヤードアーキテクチャの各層には、アーキテクチャにおける特定の役割と責務が明確にある。
プレゼンテーション層はユーザインターフェースとバックエンドとの通信ロジックに責務があり、データをどのように取得するか知る必要はないし ビジネス層はリクエストに関連した特定のビジネスルールの実行に責任があるので、どのように表示されるかを知る必要はない。
この「関心ごとの分離」は、技術によって分割されているので 開発者は特定の専門的知識を活かしてドメインの技術側面に集中することができる。
一方でこの全体的なアジリティの欠如が欠点。 ドメインで分割されたアーキテクチャとは対照的に、ある顧客ドメインはプレゼンテーション層やビジネス層、ルール層、サービス層、データベース層に散らばっているため、顧客ドメインへの変更が困難。ゆえにドメイン駆動設計のアプローチと相性が悪い。
層の分離
各レイヤーは閉鎖レイヤーと開放レイヤーに分けられる。
- 閉鎖レイヤー
- リクエストがレイヤーを上から下に移動していくさいにレイヤーをスキップせずに直下の層をしていかないといけないもの
- 開放レイヤー
- 開放レイヤーでは直接他のレイヤーを経由することなく直接そのレイヤーに到達することができる
レイヤー間のコントラクトが変更されないように、あるレイヤーの変更を他のレイヤーのコンポーネントに影響させないようにする（層の分離）には、他レイヤーの内部操作については全く知識をもたないようにすべし。
開放レイヤーのような直接的なコンポーネントへのアクセスができるようになると、他レイヤーとの相互依存性が高まり変更が困難となる高コストなアーキテクチャとなってしまう。
ただ、特定のレイヤーを開放レイヤーにしたほうが合理的なことがある。 たとえば、ユーティリティクラスのようなものはサービス層を新たに設けるなどをするのが好ましい。
考慮事項
アーキテクチャシンクホールアンチパターンには気をつける。 これは、層が具体的な処理を持たずに下のレイヤーに流してしまうだけとなっている状態を指す。 簡易的なリクエストの場合はインスタンス化と処理だけが行われ、無駄なメモリ消費が発生してしまう。
このアンチパターンは、少なくともいくつか発生するが80:20の法則で、20%のまでは許容してもよいだろうと。 80%に近づいて来たらそれは、アーキテクチャが不適切だということっぽい。
まとめ
レイヤードアーキテクチャは、予算と時間に厳しい制約がある中では優れた選択肢。 シンプルで低コストなアーキテクチャで小規模アプリケーション開発を用意にする。 また要件が定まってない状態の場合も、このアーキテクチャは優れた選択肢になる。
ただし、弾力性とスケーラビリティは非常に評価が低い。 モノリシックなデプロイメントとアーキテクチャのモジュール性の欠如によって、 アプリケーションはあるポイントまでしかスケールできない。
また耐障害性をサポートしてないという点も考慮にいれるべき。
