資料集めついでの雑記です。
層の訳としてのTierとLayer
多層アーキテクチャ、層の部分が、Tier と Layer で書かれることが多い。
この2者の違いは物理的な層、例えばクライアントマシンと、サーバーマシンが異なる場合を Tier で表記し、ソフトウェアや概念的な層を Layer と記述する。
今回は Tier に関して掘り下げていく。
2層アーキテクチャと3層アーキテクチャ
昔は各クライアントとデータベースサーバが直接接続する仕組みが存在した。それが2層アーキテクチャと呼ばれるものとしてありました。
2層アーキテクチャは以下のような欠点を抱えていました。
- クライアントにすべてのロジックを詰め込むので、UIとビジネスロジックが密結合な状態になり、いずれかを変更すると互いに影響を受けてしまう
- 複雑なことをやろうとすると処理できることがクライアントマシンのスペックに依存するため導入環境によって動きが代わってしまう
- DBと直接つながるので、人数が増えるとその分アクセス負荷も増大する。
そこで間に中間のビジネスロジックを担当するサーバを間に入れる形が提案されました。それが3層アーキテクチャです。
3層の場合はクライアント側が「プレゼンテーション層」と呼ばれるようになり、ビジネスロジックを担当するサーバは「ロジック（もしくはアプリケーション）層」、DBなどのデータを担当する部分を「データ層」という3層で呼ばれるケースが多い。
層を分けることで何を期待したのか
2層から3層に分けることで、以下のことを期待されていた
- プレゼンテーション（クライアント）側はUIだけ、ロジック層はビジネス部分の処理を、データ層はデータを管理するという形になり、機能毎に疎になる。
- クライアントとDBの間に1つ挟むことにより、裏側のデータ層のミドルウェアが変わったり、プレゼンテーション側のUIが変わっても間の層が適切なインターフェイスになっていればメンテナンスが容易。
- ビジネスロジック層は中央集権になるので、ロジックのミスなどに気づきやすい。
レイヤードアーキテクチャに置き換える
レイヤードアーキテクチャと呼ばれるものも、利点としては同じ。物理的ではなくなった分、機能ごとに層をつくりやすくなり、責務ごとに層をつくることができる。
