ソフトウェアアーキテクチャとは¶
ソフトウェアアーキテクチャとは、システムの構造を定義し、コンポーネント間の関係性や相互作用を決定する設計上の重要な決定事項の集合。
良いアーキテクチャは以下の特性を持つ：
保守性（Maintainability）: 変更が容易
拡張性（Scalability）: 成長に対応可能
テスタビリティ（Testability）: テストが容易
再利用性（Reusability）: コンポーネントの再利用が可能
理解しやすさ（Understandability）: 構造が明確
設計の重要性¶
機能要件だけではダメ¶
機能要件（何をしたいか）と非機能要件（保守性、拡張性など）という考え方がある。
例えば、機能要件だけでいえば、1つの関数にすべての処理を書いて、数百行や数千行の巨大な関数を作ることもできる。もし短期間しか使わないプログラムなら、それでも良いかもしれない。
しかし、長期間使っていくプログラムにおいては保守性や拡張性など非機能要件が重要となる。
設計（アーキテクチャ）が悪いと開発速度が落ちる¶
Accelerate社が2000社以上の組織を調査した際、「開発者1人あたりのデプロイ頻度」はハイパフォーマーの組織なら開発者の数と線形関係だったが、ローパフォーマーの組織の場合はむしろエンジニアを追加するほど生産性が落ちることが観測された。
（出所）『LeanとDevOpsの科学』
例えば、密結合したクラス
アーキテクチャパターンの重要性¶
アーキテクチャパターンは、一般的な設計上の問題に対する再利用可能な解決策を提供する。
主なメリット：
共通言語の提供: チーム内でのコミュニケーションが容易になる
ベストプラクティスの活用: 実績のある設計手法を利用できる
開発効率の向上: 一から設計する必要がない
品質の向上: 実証済みのパターンにより、バグや問題を減らせる
代表的なアーキテクチャパターン¶
単一アプリケーション内部の構造パターンは application/ に、複数サービスにまたがる分散システムのパターンは distributed/ にまとめている。
レイヤードアーキテクチャ: システムを階層に分割
クリーンアーキテクチャ: 依存関係の方向を制御し、ビジネスロジックを中心に配置
ヘキサゴナルアーキテクチャ: ポート&アダプターパターンとも呼ばれる
オニオンアーキテクチャ: ドメインモデルを中心の同心円に据える
マイクロサービスアーキテクチャ: 独立したサービスの集合としてシステムを構築
イベント駆動アーキテクチャ: イベントの生成、検出、消費に基づく設計
CQRS: コマンドとクエリの責務を分離
アーキテクチャの選択基準¶
適切なアーキテクチャを選択する際の考慮事項：
システムの規模: 小規模なアプリケーションか、大規模な分散システムか
チームの構成: チームのサイズとスキルセット
非機能要件: パフォーマンス、可用性、セキュリティなど
変更の頻度: どの程度の変更が予想されるか
技術的制約: 既存のシステムやツールとの統合
ビジネス要件: タイムトゥマーケット、コストなど
より体系的なトレードオフの考え方は アーキテクチャ特性（品質属性） を、意思決定を記録する方法は アーキテクチャ決定記録（ADR） を参照。