アーキテクチャ選択とフィットネスチェック
目標を観察可能な振る舞いに変換する
アクター、重要なワークフロー、データの所有権、制約を特定します。「スケーラブル」「セキュア」「保守しやすい」といった要件を、シナリオ（刺激→環境→応答→測定値）に変換します。設計を実質的に決定づける少数の特性に優先順位を付けます。必須の制約と好みの区別を明確にします。
手順
- 関係者とともに品質シナリオと受入しきい値を定義します。ワークロード、障害、チームに関する前提を明記します。選択を参照してください。
- 各特性が保持されるべき範囲（コンポーネント、デプロイメント、ワークフロー、システム全体）を特定します。部分ごとに異なるスタイルが正当化される場合があります。
- それらのシナリオに対して、モジュラー単一デプロイメントを含む、実現可能な少数のスタイルを比較します。それぞれの主張される利点を支えるメカニズムを説明します。
- 結合度を調査します：ソースコードの依存関係、ランタイムコール、共有データ、協調的な変更。静的なモジュール独立性は、ランタイムの障害分離を証明しません。
- 最もシンプルで実行可能なスタイルを選択し、ADR（アーキテクチャ決定記録）、その結果、および再検討のトリガーを記録します。可逆的な実装の詳細は、コストのかかる構造的コミットメントから分離しておきます。
- 重要な決定をフィットネスチェックに変換します：禁止された依存関係、契約の互換性、レイテンシ予算、復旧時間、テナント分離。フィットネスチェックを参照してください。
- 観測された負荷と変更パターンの下で再評価します。依存関係ルールの通過は一つの特性の証拠であり、アーキテクチャ全体の品質の証拠ではありません。
レビュー質問
- プラグイン境界は、実際の拡張性ニーズを解決しつつ、すべてのプラグインにコアへの無制限アクセスを許可していませんか？
- イベントには、永続的な公開、スキーマ互換性、重複排除、ラグ監視が必要ですか？これらのコストはイベント駆動提案に含まれていますか？
- 個別のデプロイメントは、測定されたボトルネックを改善するか、リリースの制約を緩和しますか？
- 提案されたチームは、結果として生じるデプロイメントと障害の複雑さを運用できますか？
- データ所有権が分割されたときに、どの不変条件が満たしにくくなりますか？
出力
品質シナリオ、候補メカニズム/トレードオフ、選択された構造、所有権/依存関係マップ、ADR、フィットネスチェック、未解決の前提を返します。
範囲と参考文献
Fundamentals of Software Architecture、第2版（Richards および Ford）に沿った部分的なカバレッジです。著者資料、公開された著者インタビューのトランスクリプト、出版社の目次、およびアーキテクチャテストのドキュメントが、このオリジナルガイドの基盤となっています。出典を参照してください。どのスタイルも普遍的な成熟段階ではありません。