第３章：Defining an Event-Driven Microservice and Its Boundaries
の前半部分の読書メモ
要約
- イベント駆動マイクロサービスで使われるメッセージのタイプとメッセージングパターンについて紹介
メッセージのタイプ
| メッセージタイプ | 目的・特徴 | 命名例 | 配信先 | 状態変更 | 備考 |
|---|---|---|---|---|---|
| コマンド | 指示・命令 | CreateOrderCommand | 単一サービス | あり | 拒否・失敗の可能性あり |
| イベント | 事実の通知 | OrderCreatedEvent | 複数サービス | なし | 拒否されない |
| ドキュメント | エンティティ全体の情報 | OrderDocument | 複数サービス | なし | 変更内容は明示されないことが多い |
| クエリ | 情報取得 | ― | 単一サービス | なし | 同期的、通常はメッセージではない |
イベントとドキュメントの使い分け
- イベントは「何が起きたか」という変化の意味を持っていて、ユーザーの行動やドメインの変更を表す。例：OrderAddressChanged
- ドキュメントはエンティティの最新状態を丸ごと伝える。例：注文全体の情報を含む OrderDocument
通常はイベント、後続サービスが全体の情報を必要とする場合はドキュメントを使う感じかな。（これ５章にあったな）
メッセージングパターン
Send/Receive パターン
- 用途：特定のサービスに命令（コマンド）を送る
- 通信形式：一対一（非同期）
-
特徴：
- あるコマンドは特定のサービスだけが受け取る
- メッセージキューを介して非同期に配信される
Request/Response パターン
- 用途：コマンドの受理確認や即座の検証結果を返す
- 通信形式：リクエスト送信＋レスポンス受信（同期または準同期）
-
特徴：
- UIがコマンドを送信し、即座に受理確認を受け取る
- 「受け付けたよ」という応答であり、処理完了を保証するものではない
- 実際の処理完了通知は別途イベントで行われる
Publish/Subscribe パターン
- 用途：イベントを複数のサービスに通知
- 通信形式：一対多（複数購読者、非同期）
-
特徴：
- 発行元はイベントをブローカーに送るだけ
- 複数のサービスが独立して購読・処理できる
- 処理完了の事実を関係するサービスに伝播させる
Send/Receive パターンとRequest/Response パターンの違い
コマンドとAPIの違いのようなものと理解（正しくはないけど大体これくらいの理解でいったん進める）
| 比較項目 | コマンド（Command） | API（Application Programming Interface） |
|---|---|---|
| 意味 | 「○○して！」という 意図を伝える | 操作対象のリソースに対する処理要求 |
| 通信方式 | 主に非同期（メッセージブローカー） | 主に同期（HTTPベース） |
| 使われる場面 | イベント駆動型アーキテクチャ | REST |
| 結果の受け取り方 | イベント通知（処理完了後） | 即時レスポンス（ステータスコード＋ボディ） |
おわり