推奨: チーム規模（15名）を考慮すると、まずModular Monolithに移行し、成長に応じて段階的にサービス分離するアプローチが現実的。

graph TD
    OP["OrderPlaced"]
    PS["PaymentService"]
    PP["PaymentProcessed"]
    PF["PaymentFailed"]
    RS["RestaurantService"]
    OA["OrderAccepted"]
    OR["OrderRejected"]
    DS["DeliveryService<br/>DriverAssigned"]
    TS["TrackingService<br/>LocationUpdated（リアルタイム）"]
    NS["NotificationService<br/>PushNotification"]

    OP --> PS
    PS --> PP
    PS --> PF
    PP --> RS
    RS --> OA
    RS --> OR
    OA --> DS --> TS --> NS

// イベント例:
{
  "type": "OrderPlaced",
  "data": {
    "orderId": "ord-123",
    "customerId": "cust-456",
    "restaurantId": "rest-789",
    "items": ["..."],
    "totalAmount": 2500
  },
  "metadata": {
    "timestamp": "2026-01-15T12:00:00Z",
    "correlationId": "corr-abc"
  }
}

メッセージブローカー選定:
  - 注文フロー: Apache Kafka（順序保証、永続化）
  - リアルタイム追跡: Redis Pub/Sub（低レイテンシ）
  - 通知: Amazon SQS（簡易キュー）

graph LR
    subgraph コマンド側（書き込み）
        PG[("PostgreSQL<br/>正規化モデル<br/>orders, order_items,<br/>payments, deliveries")]
    end

    subgraph クエリ側（読み取り）
        ES[("Elasticsearch")]
        RD[("Redis")]
    end

    subgraph ビュー例
        V1["customer_order_history<br/>顧客の注文履歴（結合済み）"]
        V2["restaurant_dashboard<br/>レストラン向け集計データ"]
        V3["delivery_tracking<br/>配達追跡用リアルタイムデータ"]
    end

    PG -->|"Debezium（CDC）"| KF["Kafka"]
    KF --> ES
    KF --> RD
    ES --- V1
    ES --- V2
    RD --- V3

遅延: 数百ミリ秒〜数秒（結果整合性）

# アーキテクチャ推奨: QuickEats次世代プラットフォーム

## 推奨: 段階的マイクロサービス移行（Strangler Fig）

### Phase 1（0-6ヶ月）: Modular Monolith化
- 既存コードをドメイン境界でモジュール分割
- イベントバスの導入（モジュール間通信）

### Phase 2（6-12ヶ月）: 高優先度サービスの分離
- リアルタイム追跡サービスの独立
- 決済サービスの独立（PCI DSS準拠）

### Phase 3（12-18ヶ月）: 完全移行
- 残りのサービス分離
- サービスメッシュ導入

### リスクと対策
- 分散システムの複雑性 → SREプラクティス導入
- データ整合性 → Sagaパターン採用
- チームスキル → 段階的な学習期間確保