Pipe and Filter

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

ソフトウェアを、プレゼンテーション層、アプリケーション層、ドメイン層、インフラストラクチャ層のように役割の異なる層に分け、上の層が下の層だけを利用するように構成するアーキテクチャパターン。階層型アーキテクチャとも呼ぶ。層ごとに役割が明確で理解しやすいが、下の層の変更が上の層に及びやすい。

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

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

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

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