アプリケーションアーキテクチャ( 21世紀の歴史)
10945 ワード
目次
n層アーキテクチャ
Admittedly created long before year 2000, this type of architecture became popular in web applications around that time.
層と層
層は、責任を切り離して、依存を管理する方法です.各層は特定の責任を有する.より高い層は下層でサービスを使用することができますが、他の方法では使用できません.
ティアは物理的に分離され、別々のマシン上で動作します.ティアは別の層に直接呼び出したり、非同期メッセージング(メッセージキュー)を使うことができます.
典型的なアプリケーションは3層で構成されます:
プレゼンテーション層は、ユーザーが対話することができる部分、例えばWebAPIを保持します.
ビジネスロジックは、ビジネス要件に関連するすべての論理を保持します.
データアクセス層は通常データベースにアクセスするためにORMを持ちます
より複雑な実装
それは3ティアに制限されません.ティアは別の層に直接呼び出したり、非同期メッセージング(メッセージキュー)を使うことができます.
各々の層がそれ自身の層でホストされるかもしれませんが、それは必要でありません.いくつかの層が同じ層でホストされるかもしれません.
利益と不利
使用するとき
ポートアダプタ
歴史
ポートとアダプタまたは六角形のアーキテクチャとして知られている、2005年にアリストアCockburnによって発明された人気のアーキテクチャです.
アプリケーションをユーザ、プログラム、自動テストまたはバッチスクリプトで等しく駆動し、開発され、最終的なランタイムデバイスとデータベースから分離してテストすることを許可する
これはDDD(Domain Driving Design Architecture)の多くの形式の一つです
動機
ポートとアダプターのアイデアは、アプリケーションがあなたのシステムの中心であるということです.すべての入力と出力は到達したり、ポートを介してアプリケーションのコアを残します.このポートは、外部技術、ツール、および配信の仕組みからアプリケーションを分離します.
利益
システムの中心に我々のアプリケーションを使用して、このポート/アダプタのデザインを使用して、アプリケーションは、それが簡単かつ高速に実行し、実装を置き換えるために、一時的な技術、ツールと配信メカニズムのような実装の詳細から分離されたアプリケーションを維持することができます.
コンポーネント
アプリケーションのビジネスロジックが発生する場所
ポートは、アプリケーションの境界を表します
外部とアプリケーションコア間の通信ポイント
これは、外部の世界と通信するコアのインターフェースです
ポートの実装
玉ねぎ建築
he Onion Architecture was introduced by Jeffrey Palermo in 2008:https://jeffreypalermo.com/2008/07/the-onion-architecture-part-1/
これはポート＆アダプターアーキテクチャの進化です.
オニオンアーキテクチャのアイデアは、ドメインとサービス層をアプリケーションの中心に配置し、プレゼンテーションとインフラストラクチャを外部化することです.
レイヤー：リング
ドメインとアプリケーション層は、アプリケーションのコアを形成します.これらの層は他の層に依存しない
これは建築の中心です.すべてのドメインエンティティが含まれます.これらのドメインエンティティには依存関係はありません
オブジェクトを格納して取得するために必要なインターフェイスを定義する責任があります.
この層は、玉ねぎの芯に扉を開く目的を持っている.サービス層もエンティティのビジネスロジックを保持することができます.この層では、サービスインターフェースはその関連から切り離されています.
コア層は他のいかなる層にも依存してはならない.
外層
それは最も外側の層であり、UIとテストのような周辺の懸念を保つ.Webアプリケーションでは、Web APIまたは単体テストプロジェクトを表します
このリングには、依存性注入原理の実装があり、アーキテクチャは中心にコアインターフェイスを含んでおり、実装はアプリケーションサービスリングの端にあります.
インフラストラクチャコア層は、DBにアクセスするには、電子メールの通知送信者、メッセージングシステムなどです.
利益と欠点
利益
短所
コマンド問合せ責任分離( CQRS )
文脈と問題
従来のアーキテクチャでは、同じデータモデルを使用してデータベースのクエリと更新を行います.それは簡単ですし、基本的なcrud操作のためによく動作します.しかし、より複雑なアプリケーションでは、このアプローチは扱いにくい.たとえば、読み取り側では、アプリケーションはさまざまな形でデータ転送オブジェクト(DTOS)を返す多くの異なるクエリを実行することがあります.オブジェクトマッピングは複雑になります.書き込み側では、モデルは複雑な検証とビジネスロジックを実装することができます.その結果、あまりにも複雑すぎるモデルで終わることができます.
読み込みと書き込みのワークロードは、しばしば非常に異なるパフォーマンスとスケール要件で非対称です.
追加の列やプロパティのような、データの読み取りと書き込みの間の不一致がしばしばあります.
解決策
CQRSアドレスは、データを更新するコマンドを使用して別々のモデルに読み込み、書き込みを別々に行い、データを読み込むクエリを指定します.
コマンドはデータ中心ではなくタスクベースであるべきです.(「予約ホテルの部屋」では予約されていない.コマンドは、同期処理されるのではなく、非同期処理のためにキューに置かれるかもしれません.
クエリはデータベースを変更しません.クエリは、任意のドメイン知識をカプセル化しないDTOを返します.
代表的
CQRS
https://docs.microsoft.com/en-us/azure/architecture/patterns/cqrs
メディア研
mediatrはメディエーターパターンのオープンソース実装です.これは、メッセージを作成し、イベントを同期または非同期パターンを使用してリッスンすることができます.
どのようにASPでMediaTRとCQRSの実装を参照してください.NETコアを大幅にコントローラのコードを簡素化することができます.
以前
[HttpPost]
public async Task<IHttpActionResult> Register (RegisterBindingModel model) {
var user = new User {
UserName = model.Email,
Email = model.Email,
DateOfBirth = DateTime.Parse (model.DateOfBirth.ToString (CultureInfo.InvariantCulture)),
PhoneNumber = model.PhoneNumber,
Name = model.Name
};
var result = await UserManager.CreateAsync (user, model.Password);
if (!result.Succeeded) return GetErrorResult (result);
return Ok (result);
}
[HttpPost]
public async Task<IHttpActionResult> Register ([FromBody] CreateUserCommand command) {
return Ok (await Mediator.Send (command));
}
次の手順
イベントソーシング
https://docs.microsoft.com/en-us/azure/architecture/patterns/event-sourcing
マイクロサービスの設計
https://docs.microsoft.com/en-us/dotnet/architecture/microservices/
次のステップは猫に対してタマネギがどのように積み上げられるかを考えることです.とマイクロサービス
写真でHalGatewood.com on Unsplash
Reference
この問題について(アプリケーションアーキテクチャ( 21世紀の歴史)), 我々は、より多くの情報をここで見つけました https://dev.to/ib1/a-brief-history-of-application-architecture-of-the-21st-century-23d4テキストは自由に共有またはコピーできます。ただし、このドキュメントのURLは参考URLとして残しておいてください。
Collection and Share based on the CC Protocol