第３章：Defining an Event-Driven Microservice and Its Boundaries
の3.1.8の読書メモ
要約
よくあるイベント駆動型の落とし穴とアンチパターンの紹介
同期レスポンスの偽装（Faking Synchronous Responses）
原則
非同期性と結果整合性を受け入れることが重要。
問題点
同期レスポンスを偽装すると、システムが高負荷時にタイムアウトや障害を起こしやすくなる。
アンチパターンの具体例
ユーザーが住所変更をリクエスト → APIが202 Acceptedを返す → バックエンドで非同期処理 → フロントエンドが変更反映をポーリングで確認。
コマンドの配信（Command Publishing）
原則
コマンドは特定のサービス・ドメインに向けて発行するべき。
問題点
複数のサービスに同じコマンドを送ると、責任範囲が曖昧になり、ドメイン分離が崩れる可能性がある。
アンチパターンの具体例
createOrderコマンドを注文サービスだけでなく、在庫サービスや通知サービスにも直接送ってしまう。これにより、注文が失敗した場合でも他のサービスが処理を進めてしまい、整合性が崩れる。
受動的攻撃イベント（Passive-Aggressive Events）
原則
イベントは「事実の通知」であり、他サービスに行動を要求すべきではない。
問題点
イベントに隠れた命令があると、設計が不明瞭になり、責任の所在が曖昧になる。
アンチパターンの具体例
「在庫が減ったイベント」が実は補充を要求しているようなケース（本来は補充コマンドを使うべき）。
これは、ちょっとわかりにくかったので以下の解釈。
在庫サービスが「在庫が少ない」と判断したなら、自分で補充サービスにコマンドを出すべきって話なんだと理解。
つまり：
❌「在庫が少ないよ〜（イベント）…誰か補充してくれるよね？」
✅「在庫が少ない！補充して！（コマンド）」
改善例
イベントは「状態の変化」を通知するだけにして、必要なアクションは別途コマンドで明示的に指示する。