macro-architecture

マクロアーキテクチャ

同じ視点の高さで機能する、相互補完的なシステムレベルのツールが2つあります。このシステムはどのような形にすべきでしょうか？

• スタイル選定 — システム／サービス／機能と、それを決定づける要件を踏まえ、どのマクロアーキテクチャスタイル（またはハイブリッド）が適しているでしょうか。また、それを選んだ場合、書籍ではどのような注意点が挙げられていますか？（Mark Richards 著 Software Architecture Patterns, 2nd ed. より。）
• 難所の分解 — システムを分解、統合、または再構成する際、現在のコードとランタイムを根拠にすると、トレードオフは実際にはどちらに傾くでしょうか？（Ford と Richards 著 Software Architecture: The Hard Parts より。）

新しいものの全体像を選ぶとき（または既存のものが妥当か確認するとき）は、スタイル選定を使います。システムを分割するか、再びまとめるかを決めるときは、難所の分解を使います。両者は組み合わせて使えます。まずスタイルを選び、その後で分解をストレステストします。

architecture-lens（手元のコードにおけるコードレベルのトレードオフ／コネセンス、およびレイヤー配置／凝集性）、domain-driven-design（境界づけられたコンテキストの境界、ユビキタス言語、コンテキスト間の統合パターン）、design-patterns（GoF のコードパターン）とは異なります。このスキルはマクロな形を選び、これらはその中のコードやコンテキストをレビューします。

判断方法の選択

必要なこと	参照先
全体的なアーキテクチャスタイルを選択または評価する	references/style-selection.md
サービスとデータ所有権を分割、統合、または再構成する	references/decomposition.md
両方	スタイルを選択してから、未解決の分解に関するトレードオフのみを評価する

現在のコード、ランタイムの証拠、ユーザーの制約を使います。実際の要件を満たす最小の一貫した形を選びます。メリット、コスト、次の具体的な手順を明示します。通常のコード変更をシステムの再設計に発展させないでください。

権限と出力

判断やレビューの依頼には、選択した方法の推奨事項を返します。ユーザーの依頼で実装が許可されている場合に限り、実装します。design-gate の場合は読み取り専用にとどめ、呼び出し元の正式なゲート結果を使用します。

ADR を作成するのは、次の3つすべてに当てはまる場合に限ります。元に戻すのが難しい、背景なしでは意外性がある、実際のトレードオフがある。3つすべてに当てはまる場合は、決定が確定した時点で既存の ADR 規約に従って記録します。フォールバック手順とヘルパーコマンドは、分解の方法に記載されています。

インタビューでは、既存の決定記録に判断、根拠、制約、参照元を追加します。この段階では、独立したレポートと実装の仕組みは適用されません。

必要な知識に絞る

選択した方法に必要な資料だけを読み込みます。

• スタイルの詳細：layered、microkernel、event-driven、microservices、space-based。
• references/traps.md：分散スタイルを推奨する前に参照します。
• references/other-styles.md：主要なマトリクスに当てはまらない場合、または粗粒度のサービスで十分な場合に参照します。
• references/catalog.md：分解、粒度、所有権、トランザクション、ワークフローに関するトレードオフを確認します。
• references/adrtemplate.md：長期的に残す判断を記録するときに参照します。