アーキテクチャに「唯一の正解」はなく、あるのは トレードオフ だけ。何を優先するかを決める軸になるのが アーキテクチャ特性（quality attributes、しばしば語尾から “-ilities” とも呼ばれる）。
代表的なアーキテクチャ特性¶
| 特性 | 説明 |
|---|---|
| 可用性（Availability） | システムが利用可能である時間の割合。障害時の復旧速度も含む |
| 拡張性（Scalability） | 負荷増加に対してリソースを追加することで対応できる度合い |
| パフォーマンス（Performance） | レイテンシ・スループットなど |
| 保守性（Maintainability） | 変更・修正のしやすさ。結合度と凝集度 がここに直結する |
| テスト容易性（Testability） | 自動テストを書きやすいか。依存の注入しやすさに強く影響される |
| セキュリティ（Security） | 機密性・完全性・可用性の確保 |
| デプロイ容易性（Deployability） | リリースの頻度・リスクの低さ |
| 相互運用性（Interoperability） | 他システムと連携しやすいか |
| 運用性（Observability） | 障害やパフォーマンス劣化を検知・診断しやすいか |
これらは互いにトレードオフの関係になることが多い（例：可用性を上げるために複製すると整合性が犠牲になりうる、 拡張性のために マイクロサービス 化すると保守性やテスト容易性が下がりうる）。 すべてを同時に最大化することはできないため、ビジネス要求に照らして優先順位をつける必要がある。
進め方¶
要求からアーキテクチャ特性を導く：非機能要件（要件定義参照）を 「どの特性がどの程度重要か」に翻訳する
優先順位をつける：全部は満たせない前提で、上位3つ程度に絞る（例：可用性 > 拡張性 > コスト）
トレードオフを明示して選択する：選んだアーキテクチャがどの特性を優先し、何を犠牲にしたかを記録する （ADR が有効）
測定可能な形にする：「可用性99.9%」「p99レイテンシ200ms以下」のように検証可能な基準に落とす
CAP定理（分散システムにおける Consistency / Availability / Partition tolerance のトレードオフ）は、 アーキテクチャ特性同士が原理的に両立しないことを示す代表例。詳細は 分散システムの整合性 を参照。