specsfy-specialist-software-architecture

ソフトウェアアーキテクチャ

使用する場面

• サービスやキュー、分散キャッシュの導入、モジュール間の境界の変更、または構造的な依存関係の方向の変更など、元に戻すコストが高い判断を行う場合に使用します。
• 品質属性（レイテンシー、可用性、一貫性、容量）を、明示的な判断基準にする必要がある場合にも使用します。
• 境界に影響しない名前変更、ファイルの移動、局所的なリファクタリングには使用しません。これらは保守作業であり、アーキテクチャ上の判断ではありません。
• 競合している境界が、まだモデル化されていないドメイン概念に関するものなら、まず $specsfy-specialist-domain-modeling を実行します。アーキテクチャが決めるのは、ドメインによってすでに定義された境界の配置であり、境界そのものを考案することではありません。

フロー

1. システムの目的、実際の制約（予算、期限、対応可能なチーム）と、測定可能な品質属性シナリオ（「スケーラブル」のような形容詞ではなく）を定義します。
2. 観測された状態を整理します。データのオーナー、モジュール／サービス間に存在する依存関係、重要なランタイムフロー、現在の問題箇所を把握します。
3. 競合する要因、後から変更するコストが高い判断、それぞれの選択肢のリスクを特定します。
4. 同じ基準（ステップ 1 のシナリオ）と、各選択肢の実際の運用コスト（ネットワーク、分散一貫性、追加の可観測性、調整が必要なチーム）を用いて比較します。
5. 定義したシナリオを満たす最小限の構造を選びます。品質属性を満たす最もシンプルな選択肢を、原則として優先します。
6. 移行中の互換性、リグレッションを検出するための可観測性、実際に実行できるロールバック手順を含む移行計画を定義します。
7. 判断を記録（ADR）し、可能であれば、自動化された依存関係テストまたは静的解析によって、提案した境界を検証します。

パターン

• 各モジュールに明確な責務、データ、インターフェースを持たせます。明示的な契約のないモジュールは、利用側にとって暗黙の結合になります。
• 変化しやすいポリシーから安定したポリシーへ依存関係を向けます（依存関係のルール）。ビジネスモジュールは、フレームワーク／インフラストラクチャの詳細に依存させません。その逆が健全なパターンです。
• 正当化できる実際の利用シナリオが測定可能な形で存在しない限り、サービス、キュー、キャッシュ、抽象化レイヤーを導入しません。先回りの抽象化は、仮説上のメリットに対して恒常的なコストを生みます。
• 実装済みのアーキテクチャ（現在存在するもの）と、目指すアーキテクチャ（移行先）を明確に分けます。これらを同じものとして扱うと、技術的負債や未完了の作業が見えなくなります。
• 品質属性はすべて測定可能なシナリオとして表現します。刺激、環境、期待される応答、測定値（例：「200 req/s の負荷で、p99 < 300ms」）を定義し、漠然とした形容詞で済ませてはいけません。
• 簡単に置き換えられる判断は局所的で可逆的なものとして扱い、後から変更するコストが本当に高い判断だけを明示的に（ADRで）記録します。
• システム全体を書き直すのではなく、検証可能で段階的なシーム（strangler fig、expand/contract）を通じてアーキテクチャを進化させます。全面的な書き直しでは期限内に完了しないことが多く、現行システムに蓄積された知識も失われます。

アンチパターン

• 正当化できるスケール、チーム、独立したデプロイに関するシナリオがないのに、「業界標準だから」という理由でマイクロサービスを採用します。分散一貫性や運用の増加に伴うコストは現実的かつ即時に発生しますが、そのメリットは該当するシナリオが現れるまで仮説にすぎません。
• Big ball of mud：境界も依存関係の方向も定義されていないモジュールで構成され、どの部分からでもほかの部分を直接呼び出せる状態です。
• 測定可能な品質シナリオがないまま、big design up front を行います。具体的な刺激による裏付けのない「将来のため」のアーキテクチャは、誤った問題を解決しがちであり、可逆的な判断を早い段階で固定してしまいます。
• 実際の利用者が現時点で 1 つしかいないのに、「将来の柔軟性」のために汎用的な間接レイヤーを追加します。柔軟性が使われるという証拠が何もないうちに、複雑さのコストを負うことになります。

検証

• クリティカルパス、障害モード、一貫性要件、キャパシティを、ハッピーパスだけでなく、定義済みのシナリオに照らして評価しています。
• 決定した依存関係の方向を固定するアーキテクチャテストまたは依存関係テストが（言語／ツールで可能な場合）用意されています。
• 移行のリハーサルを実施しています。移行中の互換性を確認し、ロールバック計画を説明するだけでなく、テストしています。
• セキュリティ、データ、運用への影響を、後からではなく意思決定の一環としてレビューしています。
• 測定可能なシナリオと、それを裏付ける証拠なしに、アーキテクチャを「スケーラブル」または「レジリエント」と宣言しないでください。証拠のない断定的な表現は禁止です。

関連するスキル

• 意思決定が外部の機能、制限、互換性に左右される場合は、$specsfy-specialist-technical-research が一次情報を収集します。
• サービス／モジュールの境界を決める前に、ドメイン概念の境界を決めるには、$specsfy-specialist-domain-modeling を使用します。
• アーキテクチャ移行のロールアウトおよびロールバック計画には、$specsfy-specialist-delivery-engineering を使用します。
• 競合する品質特性が、実際の負荷下でのレイテンシまたはキャパシティである場合は、$specsfy-specialist-performance-engineering を使用します。
• 実装したコードがここで決定した境界を守っているか確認するには、$specsfy-specialist-code-review を使用します。

アーキテクチャビュー、ADR の形式、品質特性、一次情報については、references/standards.md を参照してください。