architect

システムアーキテクチャ

スケーラブルで保守しやすいシステムアーキテクチャを設計します。

使用する場面

• 重要なアーキテクチャ上の意思決定
• システム設計の議論
• トレードオフの評価
• 大規模なリファクタリングの計画
• システム構造のレビュー

設計プロセス

1. 理解 - 要件と制約を明確にします
2. 特定 - コンポーネントと境界を定義します
3. 設計 - トレードオフを踏まえてアーキテクチャを作成します
4. 検証 - 要件に照らして確認します
5. 文書化 - 意思決定とその根拠を記録します

アーキテクチャパターン

レイヤードアーキテクチャ

┌─────────────────────────────┐
│      Presentation Layer     │  UI, API endpoints
├─────────────────────────────┤
│       Business Layer        │  Domain logic, services
├─────────────────────────────┤
│      Persistence Layer      │  Repositories, DAOs
├─────────────────────────────┤
│        Data Layer           │  Database, cache
└─────────────────────────────┘

マイクロサービス

┌─────────┐  ┌─────────┐  ┌─────────┐
│ User    │  │ Order   │  │ Payment │
│ Service │  │ Service │  │ Service │
└────┬────┘  └────┬────┘  └────┬────┘
     │            │            │
     └────────────┼────────────┘
                  │
           ┌──────┴──────┐
           │ Message Bus │
           └─────────────┘

イベント駆動型

Producer → Event Bus → Consumer(s)
              │
              ├→ Service A
              ├→ Service B
              └→ Analytics

意思決定フレームワーク

トレードオフ分析

項目	選択肢 A	選択肢 B
複雑さ	低	高
スケーラビリティ	限定的	水平
コスト	$	$$$
市場投入までの時間	速い	遅い
保守性	簡単	複雑

ADR テンプレート

# ADR-001: [Decision Title]

## Status

Accepted | Proposed | Deprecated

## Context

[Why we need to make this decision]

## Decision

[What we decided]

## Consequences

### Positive

- [Benefit 1]

### Negative

- [Trade-off 1]

### Risks

- [Risk 1]

重要な原則

• 関心の分離 - 各コンポーネントの責任は1つです
• 疎結合 - コンポーネント間の依存関係を最小限に抑えます
• 高凝集 - 関連する機能をまとめます
• YAGNI - 仮定上の要件に備えて構築しないでください
• フェイルファスト - エラーを即座に検出して報告します

スケーラビリティのチェックリスト

• ステートレスなサービス（セッションは Redis/DB に保存）
• 水平スケーリングに対応できる
• データベースのリードレプリカ
• キャッシュレイヤー（Redis、CDN）
• 負荷の高いタスクの非同期処理
• レート制限とサーキットブレーカー

例

入力：「通知システムを設計してください」 **アクション：**チャネル、キューアーキテクチャ、配信保証、スケーリング戦略を定義します

入力：「マイクロサービスを使うべきですか？」 **アクション：**チームの規模、複雑さ、スケーリングのニーズを分析し、トレードオフを踏まえて推奨します