第1章：レイヤ化：エンタープライズアプリケーションアーキテクチャパターン（PoEAA）、メモ

第一章レイヤ化

序論

レイヤの重要性について、論じている。ネットワークのOSI参照モデルも7つのレイヤに分けている。これも、レイヤ間の依存性を最小限にできる、レイヤ単位で分割して考えることができる、レイヤ単位での標準化がやりやすいなどのメリットがある。

memo: ネットワークの切り分けなども、このレイヤごとに切り分けを行うことが多い。

ケーブル被疑（ケーブルが抜けている等）：レイヤ1の物理層

データリンク層被疑（LANケーブルのストレート/クロスケーブルの使い分け、スイッチポート設定）：レイヤ2

ネットワーク層被疑（IPアドレス/サブネットマスク、ルーティング）：レイヤ3

トランスポート層被疑（TCP/UDP）：レイヤ4

アプリケーション層被疑（ファイアウォール、WAFなど）：レイヤ7

1.1エンタープライズアプリケーションのレイヤの発展

しかし、ビジネスロジックがすべてリッチクライアントに埋め込まれている場合は、すべてのビジネスロジックを作り直してWebインタフェースを持たせなければならない。適切に設計された3レイヤシステムなら、新しいプレゼンテーションレイヤを加えるだけでこれを行うことができる。

レイヤ単位に適切分割されていれば、レイヤ単位でのみの修正で済む。

レイヤとティアの違い

ティアは、物理的に区別されるもの、との捉え方

クライアント/サーバシステムは、2ティアシステムとして捉えられる。クライアントはデスクトップ、サーバはサーバと考えると、基本は異なる物理マシンである

一方、レイヤは異なるマシンでレイヤを実行する必要はない

1.2 3つの主なレイヤ

プレゼンテーションレイヤ、ドメインレイヤ、データソースレイヤに分けられる。

プレゼンテーションレイヤ：システムの見た目の部分

ドメインレイヤ：システムのロジック部分

データソースレイヤ：データベースとの通信部分

1.3 レイヤの実行場所の選択

クライアントとサーバ、どちらで処理を実行すべきか

プレゼンテーションレイヤ：UIの種類によって決まることが多い。どちらもありうる。

ドメインレイヤ：サーバで実行することが保守を容易にするために最善の選択。クライアントのみ、サーバのみ、クライアントとサーバ両方も可。

クライアントのみ：バージョンアップと保守の作業が増える

サーバのみ：保守が容易

クライアントとサーバ両方：どこにロジックがあるのかわからなくなる恐れ

データソースレイヤ：常にサーバで実行される。例外は、サーバとの切断時に操作を行いたい時に、サーバの機能を適切かつ強力なクライアントに複製する場合。

Notionの場合は、サーバ接続中はそのまま同期的に処理しつつ、サーバとの接続が切れ、復旧後にまた同期を開始する感じとなる

ヘキサゴナルアーキテクチャ