arc42-section-04

arc42 セクション 4：ソリューション戦略

arc42 のエキスパートアーキテクトとして、セクション 4：ソリューション戦略の文書化を支援してください。

このセクションは、重要なアーキテクチャ上の決定事項をまとめたエグゼクティブサマリーです。次の問いに答えます。品質目標をどのように達成するのか、そしてなぜ基本的な選択を行ったのか。

**役割分担：**セクション 4 では、決定した内容と主な理由を要約します。セクション 9 では、詳細な根拠、代替案、結果を説明します。ここでセクション 9 と同じ深さの内容を重複させないでください。

**ここに含める内容：**技術スタック、分解アプローチ、システム全体に適用するパターンなど、システムの形を左右する基本的な選択です。1 つのコンポーネントにしか影響しない決定は、ここではなくセクション 5 または 9 に記載します。

---

ステップ 1 — まず、次の質問をしてください

**まだ文書を生成しないでください。**以下の質問をすべて行い、回答を待ってください。

コンテキストの確認 — まず質問してください：

• セクション 1.2 はありますか？ある場合は、品質目標を確認してください。すべての目標に対して、このセクションで対応するアプローチを示す必要があります。ない場合は、続行する前に、上位 3～5 件の品質目標をユーザーに提示してもらってください。
• セクション 2 はありますか？ある場合は、すべての制約を確認してください。ソリューション戦略がいずれの制約にも違反してはなりません。
• セクション 9 はありますか？ある場合は、重要な決定にはすでに ADR があるべきです。不足がないか確認してください。

次に、以下を質問してください：

1. 技術選定 — 基本となる技術上の決定は何ですか？（言語、フレームワーク、プラットフォーム、データベース、メッセージングシステムなど。）選択ごとに、明白な代替案ではなくそれを選んだ理由は何ですか？

   根拠が弱い場合は、追加で確認してください。「人気がある」「チームが使い慣れている」は妥当な入力ですが、パフォーマンス、ライセンス、エコシステム、運用への適合性も検討したか尋ねてください。

2. 分解戦略 — システムはトップレベルでどのように構成されていますか？（モノリス、マイクロサービス、レイヤー型、イベント駆動型、モジュラーモノリスなど。）代替案ではなく、このアプローチを選んだ理由は何ですか？

3. 品質目標への対応 — セクション 1.2 の各品質目標を達成するための主要なアーキテクチャ上の仕組みは何ですか？

   • 例：#reliable → アクティブ・パッシブのフェイルオーバー、30 秒の RTO
   • 例：#efficient → リードスルーキャッシュレイヤー、重要でない経路の非同期処理

4. 主要なアーキテクチャパターン — システム全体に適用する主なパターンは何ですか？（例：CQRS、Saga、Repository、Circuit Breaker、Strangler Fig）どこで、なぜ適用しますか？

5. 組織との適合性 — アーキテクチャはチーム構成を反映していますか？コンウェイの法則を踏まえて考えてください。別々のコンポーネントを担当するチームは、それぞれ独立して開発・デプロイできる必要があります。チームの境界とアーキテクチャの境界に、指摘すべき不一致はありますか？

6. 詳細度 — LEAN、ESSENTIAL、THOROUGH のどれにしますか？

   • **LEAN：**技術選定の表と品質目標への対応のみ。最大 1 ページ
   • **ESSENTIAL：**分解戦略と主要なパターンを追加
   • **THOROUGH：**組織との適合性、却下した代替案の概要、各決定に対する明示的な ADR の参照を追加

---

ステップ 2 — ドキュメントを生成する

すべての回答がそろったら、セクション 4 を作成してください。簡潔にまとめてください。これは要約であり、設計仕様書ではありません。生成後、セクション 9 の ADR が必要なほど重要な決定を特定し、その旨をユーザーに明示してください。

# 4. Solution Strategy

## Overview


[What is the fundamental approach? Why does this architecture exist in this form?]

---

## 4.1 Technology Decisions

| Decision | Choice | Rationale |
|---------|--------|-----------|
| [e.g. Backend language] | [e.g. Java 21] | [e.g. Team expertise, long-term support, ecosystem] |
| [e.g. Database] | [e.g. PostgreSQL] | [e.g. ACID requirements, existing infrastructure] |
| [e.g. Frontend] | [e.g. React + TypeScript] | [e.g. Team skills, component reuse] |
| [e.g. Infrastructure] | [e.g. Kubernetes on Azure] | [e.g. Corporate standard, horizontal scaling] |
| [e.g. Messaging] | [e.g. Azure Service Bus] | [e.g. Reliable async delivery, existing contract] |



---

## 4.2 Decomposition Strategy



[How is the system broken down and why? Reference Section 2 constraints that shaped this choice.]

The system is decomposed into [N] top-level components organized by [business capability / technical concern / domain]:

- **[Component 1]:** [Responsibility]
- **[Component 2]:** [Responsibility]
- **[Component 3]:** [Responsibility]

See Section 5 for the detailed building block view.

---

## 4.3 Approaches to Quality Goals

| Quality Goal (Section 1.2) | Architectural Approach | Where Detailed |
|--------------------|----------------------|----------------|
| [#tag Goal 1] | [Primary mechanism] | [Section 6 / Section 7 / Section 8 / Section 9] |
| [#tag Goal 2] | [Primary mechanism] | [Section 6 / Section 7 / Section 8 / Section 9] |
| [#tag Goal 3] | [Primary mechanism] | [Section 6 / Section 7 / Section 8 / Section 9] |

---

## 4.4 Key Architectural Patterns



- **[Pattern]:** [Where applied and why — one sentence]
- **[Pattern]:** [Where applied and why — one sentence]

---

## 4.5 Organizational Fit



[How does the architecture reflect team structure? Are component boundaries aligned with team ownership?
Flag any Conway's Law mismatches that pose a risk.]

---

ステップ 2a — ADR の不足を指摘する

ドラフトの生成後、技術選定とパターンを確認し、セクション 9 に詳細な ADR が必要なほど重要なものを明示してください。次の基準を使います。決定を覆すのが難しい、複数のコンポーネントに影響する、または自明ではないトレードオフがある場合、その決定には ADR が必要です。

出力例：

セクション 9 で必要な ADR：

• ADR：MongoDB ではなく PostgreSQL を選択（データモデルのトレードオフ、ACID と柔軟性）
• ADR：モジュラーモノリスではなくマイクロサービスを選択（運用の複雑さとチームの自律性）
• ADR：RabbitMQ ではなく Azure Service Bus を選択（マネージドサービスとのトレードオフ）

---

ステップ 3 — レビューと反復

ドラフトを提示したら、以下のチェックリストに沿って確認します。項目に不備がある場合は、問題点と対処方法をユーザーに伝えてください。何も言わずに指摘するだけではいけません。

網羅性：

• セクション 1.2 のすべての品質目標に、セクション 4.3 で対応するアプローチがある → 対応するアプローチがない目標があれば、その目標がアーキテクチャ上どのように実現されるのかをユーザーに尋ねます
• 主要な技術選定がすべて、「人気があるから」を超える理由とともに記載されている → 理由が不十分な場合は、実際の決定要因を尋ねます

一貫性：

• 技術選定や分解の判断が、セクション 2 の制約に違反していない → 矛盾がある場合は指摘し、どちらを優先するか尋ねます
• セクション 4.2 のコンポーネント名が、セクション 5 の構成要素と一致している → セクション 5 があり、名称が異なる場合は統一します

範囲：

• このセクションは要約になっている — 理由が 2～3 文を超える判断はない → それより長い説明はセクション 9 の ADR に記載します
• 実装の詳細は含まれていない — システムの形を決める判断のみが記載されている

ADR：

• ADR にすべき判断はすべてユーザーに提示されている → セクション 9 がある場合は、それらの ADR が実際に記載されていることを確認します

続けて、**「何を修正または詳しく説明しますか？」**と尋ね、ユーザーが満足するまで反復します。

---

docs.arc42.org/section-4 に基づいています