4層（N層用）アーキテクチャの例？
最近、私の友人からN-Tierアーキテクチャについて質問があり、1、2、3層アーキテクチャについて例を挙げて説明することができました。しかし、3層以上の例を挙げたいと思ったときに行き詰まりました。私はググって助けを求めましたが、適切な例は見つかりませんでした。
Nティアという名前が付けられているため、「N」は1から始まる任意の数にできると思いますが、4ティアや5ティアの例は見つかりませんでした。
3層を超えるN層アーキテクチャの例を誰かが共有できますか？
- 基本サービス：例データベース、ディレクトリサービス、ファイルと印刷サービス、ハードウェアの抽象化。この層はますますプラットフォームと呼ばれています。
- ビジネスドメイン層：EJB、DCOM、CORBAサービスオブジェクトなどのJavaEEなどのアプリケーションサーバー。 SOAおよびマイクロサービスを使用して、ビジネス機能を提供します。
- プレゼンテーション層：例Javaサーブレット/ JSP、ASP、PHP。この層には、ビジネス層サービスのプロキシおよびアダプタとしてWebServicesが含まれるようになります。
- クライアント層：ブラウザ上のHTMLページのようなシンクライアントとJava WebStart＆Flash。のようなリッチクライアント
- Java EEでは、ビジネスドメイン層をデータアクセス（エンティティBean）とビジネスサービス（セッションBean）に分割するのが一般的です。
- エンタープライズでは、SOA（サービス指向アーキテクチャー））ESBは通常、層1と2の間に追加の層として存在します。これは、プラットフォームのプロビジョニングの一部である場合があります。
- マッシュアップでは、ティア3とティア4の間に集約ティアを配置できます。
Nティアと呼ばれるようになったのは、古いクライアントサーバーから最初の3ティア、次に4ティアへとコンポーネント化が進むアーキテクチャへの移行を反映しています。層の定義特性は、関心の分離を備えた明確に定義されたインターフェースです。
5分前にこの記事を読みました https://www.nginx.com/blog/time-to-move-to-a-four-tier-application-architecture
クライアントはあなたがそれを読む場所ですApiまたはあなたのアプリケーションバックエンドはあなたがそれを組み立てる場所です..データ集約..アウトソーシングされたものからjsons/xmlを通過するか、またはデータベース上のクエリ、そして最後にサービス層が実際にクエリを行う場所ですデータベースで、またはビッグデータで関数を実行するか、GoogleからGPSの位置と地図を読み取ります...この場合、このように表示されます。データ層を3層から単純に分割しました。
ただし、このN層モデルは完全に抽象的であるため、論理的にアトミックな部分だけになるまでインフラストラクチャを引き裂くことができます。以前の構造を分割しています。
私は、「どのように、そしてなぜシステムを層に分割し、それらをサーバーのどこに配置するのか」という質問に答える、より抽象的でなくより実用的な説明に傾いています。
基本的に、データベースを使用する単純なWebサイトを作成すると、「箱から出して」すぐに3層になります。
データ層-データベース。ただし、短期間のメモリキャッシュまたはファイルシステムを使用している場合は、それを「階層」と見なすことができるかどうかについて議論することがあります。
アプリケーション層-サーバーで実行されるコード。
プレゼンテーション（またはクライアント）層-クライアントのマシンで実行され、結果をクライアントに提示するコード
では、どのようにして第4層を取得しますか？
おそらく、クライアント層を分割する必要はありません。それはクライアントのデバイス上にあり、できるだけシンプルかつ効率的にしたいと考えています。
データ層を分割できますか？ティアと見なすことができるサブシステムを作成するために、データベース、Azure Blob、ファイルシステムなどのAPIを備えたシステムをいくつか見ました。しかし、それは依然として同じデータ層（別名、基本的なサービス層）ですか、それとも別個のエンティティと見なすことができますか？それを分離すると、データベースと同じ物理（または仮想）サーバー上にあるので、直接アクセスからデータを保護できますか？
ただし、ほとんどの場合、分割されるのはアプリケーション層です。
一部はまだアプリケーション層と呼ばれています。これは内部API Webアプリケーションになり、データベースにアクセスできる保護されたゾーンに存在します。誰もデータベースに直接アクセスできませんが、このアプリケーション層を介してのみアクセスできます。
もう1つの部分は、なんらかの接続（HTTPクライアントなど）を介してアプリケーション層APIのコンシューマーになります。コンシューマーは、それ自体がJSON APIのみを持ち、ユーザーフレンドリーな形式を持たない場合でも、プレゼンテーション層と呼ばれる可能性があります（混乱します-クライアント層と同じではありませんか？）。
しかし、その後、問題が発生します。私たち開発者は、同じWebアプリケーション内のレイヤーとして保持するのではなく、私たちの生活を複雑にし、Webアプリケーションをプレゼンテーション層とアプリケーション層に分割したいと思うかもしれません。
深刻なワークロードでは、独立したアプリケーション層がスケーラビリティに優れている場合や、ユーザーに公開されているWebサーバー（イントラネットのものも含む）へのデータベース接続を拒否することがセキュリティの要件である場合があります。
私はいくつかの野心的なプロジェクトを最初から4層に行ってから、過剰設計のために自分を罵倒しているのを見てきました。これらの内部接続、セキュリティ、認証トークンを追跡し、ソケットを制御下に維持し（すべての要求で新しいHTTP接続を開かないようにする）、不注意で作成されたグローバルHTTPクライアントインスタンスを介して複数の並列要求のデータを誤って共有しないようにします。