マイクロサービスアーキテクチャ

システムを、独立して開発・配置できる小さなサービスの集まりとして構成する方式。サービス単位で改修や増強ができる一方、サービス間の通信やデータの整合性の管理は複雑になる。

アプリケーションを独立してデプロイ可能な小さなサービスの集合として構築するアーキテクチャスタイル。各サービスが独立して開発・デプロイでき、スケーラビリティと保守性が向上する。モノリシックアーキテクチャと対比される。

アプリケーションを小さな独立したサービスの集合として構築するアーキテクチャスタイル。各サービスは独自のデータストアを持ち、APIを通じて通信する。独立した開発・デプロイ・スケーリングが可能だが、分散システムの複雑さが増す。

アプリケーションを、業務の機能ごとに独立して開発・配備・拡張できる小さなサービスの集まりとして構成するアーキテクチャ。サービスどうしはAPIで通信し、それぞれが自分のデータを持つ。サービスごとに更新や拡張ができる一方、サービス間の通信の遅延や障害、分散したデータの整合性の管理が課題になる。

アプリケーションを、業務の機能ごとに独立して開発・デプロイ・拡張できる小さなサービスの集まりとして構成するアーキテクチャ。各サービスはAPIで通信し、それぞれ別のデータストアを持つことが多い。変更や規模の拡大に柔軟に対応できる一方、分散システムとしての運用や整合性の確保が難しくなる。

分散システムにおいて、一貫性（Consistency）、可用性（Availability）、分断耐性（Partition tolerance）の3つを同時に満たすことは不可能であるという定理。システム設計時にどの2つを優先するかを選択する必要がある。

単純で固定長の命令セットを採用し、パイプライン処理による高速化を図るプロセッサアーキテクチャ。命令数を絞り1クロックで1命令を実行する設計思想。ARM、MIPS、RISC-Vが代表例。CISCと対比される。

豊富で複雑な命令セットを持ち、1命令で複数の処理を実行できるプロセッサアーキテクチャ。可変長命令でプログラムサイズを小さくできるが、パイプライン処理が複雑になる。x86アーキテクチャが代表例。

データベースの構造を外部スキーマ（利用者やアプリケーションから見たデータ定義）、概念スキーマ（データベース全体の論理的構造）、内部スキーマ（物理的な格納方式）の3層に分離するアーキテクチャ。データの独立性を確保し、一方の変更が他方に影響しにくくする。

ソフトウェアをModel（データと業務ロジック）、View（表示）、Controller（入力制御）の3つの役割に分離するアーキテクチャパターン。UIと業務ロジックを分離することで保守性と再利用性を高める。Webアプリケーションで広く採用されている。

組織全体の業務とシステムを、ビジネス・データ・アプリケーション・テクノロジの4つの体系で整理・最適化する手法。全体最適の観点から情報システムのあるべき姿を設計する。