クリーンアーキテクチャ

ソフトウェアの依存関係を内側（ビジネスロジック）から外側（UI・DB等）への一方向に制御するアーキテクチャパターン。レイヤー間の疎結合を実現し、テスト容易性と保守性を高める。

Robert C. Martinが提唱したアーキテクチャパターン。エンティティ、ユースケース、インタフェースアダプタ、フレームワーク・ドライバの同心円構造で、依存関係を内側に向ける。ビジネスルールを外部技術から独立させることを目的とする。

Robert C. Martinが提唱したアーキテクチャパターン。エンティティ、ユースケース、インタフェースアダプタ、フレームワーク・ドライバの同心円構造で、依存関係を内側に向ける。ビジネスルールを外部技術から独立させることを目的とする。

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

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

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

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

業務上のルール、計算、判断など、ソフトウェアが対象とする業務の領域に固有の処理。ビジネスロジックとも呼ぶ。画面の表示やデータベースへのアクセスなどの技術的な処理から分けてまとめることで、業務の変更に対応しやすくする。

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