レイヤードアーキテクチャ

ソフトウェアを複数の層に分離し、各層が直下の層のみに依存する構造のアーキテクチャスタイル。プレゼンテーション層、ビジネスロジック層、データアクセス層などに分ける。関心事の分離と変更の局所化を実現する最も基本的なパターン。

必要最小限の機能を持つコアシステムに、個別の機能をプラグインとして追加していくアーキテクチャパターン。プラグインアーキテクチャとも呼ぶ。コアを変えずに機能を拡張・交換でき、統合開発環境（IDE）やWebブラウザの拡張機能が例。

処理を行う多数の処理単位が、データを共有のデータベースではなく、各単位のメモリ上に複製したデータ（インメモリのデータグリッド）で扱うアーキテクチャパターン。データベースへのアクセスがボトルネックにならないので、アクセスが急増しても処理単位を増やして対応できる。データベースへの反映は非同期で行う。

コマンドクエリ責務分離。データを更新する処理（コマンド）と参照する処理（クエリ）のモデルを分けるアーキテクチャパターン。更新と参照で別のデータモデルやデータストアを使い、それぞれを独立して最適化・拡張できる。更新の結果が参照のモデルに反映されるまでに遅れが生じることがある。

ソフトウェアを、中心の業務ルール（エンティティ、ユースケース）から外側の画面、データベース、フレームワークまでの同心円状の層に分け、依存の向きを常に外側から内側へ向けるアーキテクチャ。ロバート・C・マーチンが提唱した。業務ルールが技術的な詳細に依存しないので、データベースやフレームワークを替えやすく、業務ルールを単独でテストできる。

GUIアプリケーションを、データと業務ロジックを持つModel、画面表示を担うView、両者を仲介するPresenterの3つに分けるアーキテクチャパターン。ViewはPresenterを通じてのみModelとやり取りし、表示の制御をPresenterに集めるため、画面を伴わない単体テストがしやすい。MVCから派生したパターンである。

アプリケーションをModel（データと業務ロジック）、View（画面）、ViewModel（画面に表示する状態と操作）の3つに分けるアーキテクチャパターン。ViewとViewModelをデータバインディングで結び付け、画面の更新を自動化する。MVCから派生し、GUIアプリケーションやフロントエンドフレームワークで使われる。