第01章：ドメインイベントってなに？🌱✨
🎯 ゴール
- 「Domain Events（ドメインイベント）」を “業務で起きた事実” として説明できるようになる💡
- “何をするか”じゃなくて “何が起きたか” で表せるようになる（例：「OrderPaid」）⏳✨
1) ドメインイベント＝「大事な出来事のレシート」🧾✨
ドメインイベントはひとことで言うと、
- ✅ 「ドメイン（業務）で、もう起きた出来事」
- ✅ 「その出来事を、他の処理が知れるように“かたち”にしたもの」
…です📣
「イベントは過去の出来事」っていうのが超大事ポイントで、 “これからやる命令” じゃなくて “すでに起きた事実” を表します🕰️
Martin Fowler も、ドメインイベントを「（アプリが気にする）外の世界で起きた出来事」として語っています。 (martinfowler.com) また Microsoft の解説でも「ドメインイベントは、起きたこと（過去）で、同じドメイン内の他の部分に知らせたいもの」と説明されています。 (Microsoft Learn)
2) 「命令」と「事実」の違いを一発で理解しよう⚡🧠
🟥 命令（Command）＝「やって！」
- 「メールを送れ」
- 「支払いを実行しろ」
- 「発送して」
🟩 事実（Event）＝「起きた！」
- 「メールが送信された」
- 「支払いが完了した」
- 「発送された」
ドメインイベントは 🟩側 です🙌✨ だから名前も、だいたい 過去形っぽい雰囲気 になります（英語の命名でも “～ed”/過去分詞っぽさ）📝
3) 例：ミニECだと、どんなイベント？🛒📦💳
「注文→支払い→発送→通知」みたいな流れがあるとき、イベントはこんな感じ👇
- ✅ OrderPlaced（注文された）🧾
- ✅ OrderPaid（支払いが完了した）💳
- ✅ OrderShipped（発送された）📦
- ✅ ReceiptIssued（領収書が発行された）🧾✨
- ✅ CustomerNotified（通知された）📩
ポイントは、どれも 「もう起きた」 になってること🌟
4) なんでイベントがあると「後から追加」がラクなの？🔌✨
イベントがない世界だと…
- 注文処理の中に「メール送信」「ポイント付与」「売上集計」などがどんどん混ざりがち😵💫
- 追加したいことが増えるたびに、注文処理が巨大化💥
- うっかり既存処理を壊す確率も上がる🧨
イベントがある世界だと…
- 「注文が支払われた」という事実（OrderPaid）を合図にして📣
- あとから「ポイント付与」を追加しても、支払い処理にベタ書きしなくて済む🎁✨
- 「通知」「集計」「連携」を 別の処理として増やしやすい 🔌🧩
つまり、イベントは “あとから増やすための接続口” になってくれます🔌✨
5) ドメインイベントは「ログ」と何が違うの？🪵👀
よく混ざるので、ここで分けちゃうね💡
-
🧾 ドメインイベント：業務的に意味がある「出来事」
- 例）「支払いが完了した」「発送された」
-
🪵 ログ：観測のための記録（デバッグや運用）
- 例）「支払いAPIにリクエスト送った」「レスポンス200」
-
🔔 通知：誰かに伝えるためのアクション
- 例）「メール送信」「Slack投稿」
ドメインイベントは “意味のある出来事そのもの”。 ログや通知は、その出来事の周辺にある別の目的のもの、ってイメージがいちばん安全✅✨
6) TypeScript（2026）で見る「イベントの姿」🔷🧩
TypeScript は 2026年1月時点で 5.9 の情報が公開されています（公式のRelease Notes/ブログ）。 (TypeScript) この教材では「イベントを型で安全に扱える」のが強みになるよ🛡️✨
ここでは “雰囲気” をつかむだけでOK👌（まだ環境セットアップ前でも読める）
// 「ドメインイベントって、だいたいこういう情報を持つよね」の最小イメージ🧾✨
type DomainEvent<TType extends string, TPayload> = {
eventId: string; // そのイベントのID（ユニーク）🆔
occurredAt: string; // 起きた時刻（ISO文字列など）🕰️
type: TType; // イベント名（例: "OrderPaid"）🏷️
payload: TPayload; // 内容（必要最小限がコツ）🎒
};
// 例：支払い完了イベント💳
type OrderPaid = DomainEvent<"OrderPaid", {
orderId: string;
paidAmount: number;
}>;
「type と payload を “イベントごとに型で縛れる”」のが TypeScript っぽい美味しさ😋🔷
7) 📝 演習：日常の出来事を「過去形の事実」にして5個書こう📒✨
ルール（超かんたん）✅
- 「やる」じゃなくて「起きた」にする
- “業務っぽい/意味がある” 出来事にする（小さすぎるのは避ける）
例（このまま真似してOK）🍀
- LessonFinished（授業が終わった）🎓
- LunchOrdered（ランチを注文した）🍙
- PartTimeShiftStarted（バイトが始まった）🕒
- ReportSubmitted（レポートを提出した）📄
- TrainMissed（電車に乗り遅れた）🚃💨
あなたの番✍️
- ＿＿＿＿＿＿＿＿
- ＿＿＿＿＿＿＿＿
- ＿＿＿＿＿＿＿＿
- ＿＿＿＿＿＿＿＿
- ＿＿＿＿＿＿＿＿
8) 🤖 AI活用：イベント名の候補を10個出してもらって「粒度」を比べよう🔍✨
🎯 やりたいこと
- 1つの出来事に対して、イベント名候補をたくさん出して
- 「大きすぎ？」「細かすぎ？」を比べて、ちょうどいいところを見つける⚖️
コピペ用プロンプト（そのまま使ってOK）📋✨
プロンプト①：候補を10個
- 「『◯◯（出来事）』を表すドメインイベント名を英語で10個ください。過去形の事実になるようにしてください。候補ごとに“粒度が大/中/小”も付けてください。」
プロンプト②：命令→事実に変換
- 「次の“命令っぽい名前”を、ドメインイベント（過去の事実）になるように言い換えてください：SendEmail, DoPayment, ShipOrder。各3案ずつ。」
プロンプト③：粒度チェック
- 「このイベント名は粒度が大きすぎますか？小さすぎますか？理由と改善案をください：OrderProcessed」
9) よくあるミスあるある🚧（ここだけ先に回避しよう！）
❌ ミス1：イベント名が命令になってる
- SendEmail / DoPayment みたいな “やれ” はイベントじゃないことが多い🙅♀️
- ✅ CustomerNotified / PaymentCompleted みたいに “起きた” に寄せよう✨
❌ ミス2：技術の都合が名前に出てる
- KafkaPublished とか DBUpdated とかは “業務の出来事” じゃない😢
- ✅ あくまで業務：OrderPaid / AddressChanged みたいにする🧾
❌ ミス3：なんでもイベントにしてカオス
- 「ボタンが押された」「画面が開いた」みたいなのは、業務上の意味が薄いことが多い📱💦
- ✅ “ビジネス的に意味がある” を基準にしよう✨
✅ まとめチェック（3つだけ！）🧠✨
- ✅ ドメインイベントは 「起きた事実」（過去）🕰️
- ✅ 名前は “何が起きたか” を表す（命令にしない）🧾
- ✅ イベントがあると あとから機能を足しやすい 🔌✨
🧷 おまけ：2026時点の実行環境の空気感（超ざっくり）🪟✨
（この教材では細かいセットアップは別章でやるよ！ここは安心材料だけ☺️）
- Node.js は v24 が Active LTS 扱いとして整理されていて、v25 は Current です（公式のリリース一覧）。 (Node.js)
- 2026-01-13 に v24.13.0（LTS）のセキュリティリリースも出ています。 (Node.js)
「最新を追いつつ、安定版（LTS）も意識する」っていう流れでOKだよ🙆♀️✨