Skip to main content

ドメインイベント(Domain Events):32章アウトライン(C# / 2026 / Windows)💉🧩🪟

第1章 この教材でできるようになること🎓✨

  • ねらい🎯:ドメインイベントを使って「追加に強い設計」を作れるようになる

  • 学ぶこと📚

    • ドメインイベント=「起きた事実」🔔
    • “巨大メソッド化”を防ぐ考え方🧩
  • やってみよう🛠️:ミニECで「注文→支払い→発送」を題材に進める🛒💳📦

  • チェック✅:イベントは“命令”じゃなく“事実”として扱う


第2章 まずは超基本:コマンドとイベントの違い📣🤔

  • ねらい🎯:混同しがちな2つをスッキリ分ける

  • 学ぶこと📚

    • Command(命令)🧑‍✈️「支払って!」
    • Event(事実)📢「支払いが完了した」
  • やってみよう🛠️:例を10個並べて「命令/事実」を分類ゲーム🎮✨

  • チェック✅:イベントは基本“過去形”🕒


第3章 ドメインってなに?(設計の超入口)🏷️🙂

  • ねらい🎯:業務ルールをコードの中心に置く感覚をつかむ

  • 学ぶこと📚

    • ドメイン=「業務のルール・意味」❤️
    • UI/DB/外部APIは“詳細”🔌
  • やってみよう🛠️:ミニECの「守りたいルール」を箇条書き📝

  • チェック✅:「画面の都合」でルールを決めない


第4章 関心の分離(SoC)を最短で理解する✂️✨

  • ねらい🎯:“混ぜると辛い”を体感する

  • 学ぶこと📚

    • 変更理由が違うものは分ける(通知/永続化/表示 など)📦
  • やってみよう🛠️:「注文確定」の処理を“関心ごと”で色分け🧠🖍️

  • チェック✅:同じメソッドで全部やらない🙅‍♀️


第5章 例題の全体像:ミニECのストーリー🛒📦

  • ねらい🎯:教材全体の地図を持つ

  • 学ぶこと📚

    • 注文(Order)➡️ 支払い(Payment)➡️ 発送(Shipment)
    • 状態(Status)という考え方🔁
  • やってみよう🛠️:状態遷移をざっくり書く(未払い→支払済→発送済)🗺️

  • チェック✅:「支払い前に発送しない」などの不変条件を意識


第6章 用語をそろえる:ユビキタス言語ごっこ🗣️🎀

  • ねらい🎯:“同じ言葉”で会話できるようにする

  • 学ぶこと📚

    • Order/Payment/Shipment の意味を一言で定義📌
    • “Paid” と “Settled” みたいな言葉の揺れを防ぐ🧷
  • やってみよう🛠️:用語集(5〜10語)を作る📖

  • チェック✅:イベント名も用語集の言葉で作る


第7章 開発環境(Windows + Visual Studio)最小セット🪟🛠️

  • ねらい🎯:迷わず動くプロジェクトを用意

  • 学ぶこと📚

    • Visual Studio(最新版)での基本操作🧰
    • .NET/C#(2026時点の最新版)プロジェクト作成🧩
  • やってみよう🛠️

    • ソリューション作成→実行→デバッグ(ブレークポイント)🧪
  • チェック✅:まず「実行できる」状態が正義🏁


第8章 (任意)Visual Studio Code版の最小セット💻✨

  • ねらい🎯:軽い環境でも進められるようにする

  • 学ぶこと📚

    • .NET SDKの確認・ターミナル実行⌨️
  • やってみよう🛠️:同じ例題をVS Codeで起動してみる🔁

  • チェック✅:環境が違っても“設計の考え方”は同じ


第9章 AI拡張を前提にした進め方🤖🧠

  • ねらい🎯:AIを“便利な相棒”として安全に使う

  • 学ぶこと📚

    • 使いどころ:雛形生成・命名案・テスト案・リファクタ案🧩
    • 注意:設計判断は“目的”から人が決める🎯
  • やってみよう🛠️:良いプロンプト3種類(雛形/レビュー/テスト)を作る📝

  • チェック✅:生成コードは必ず自分の言葉で説明できる


第10章 ソリューション構成:置き場所ルール🏠📦

  • ねらい🎯:ごちゃ混ぜを防ぐ

  • 学ぶこと📚

    • 例:Domain / Application / Infrastructure / Presentation の分け方🧱
  • やってみよう🛠️:プロジェクトやフォルダを作って“役割”をメモ🗂️

  • チェック✅:ドメインにDBやHTTPの型を入れない🙅‍♀️


第11章 ドメインモデル入門:EntityとValueObject🌸

  • ねらい🎯:イベントの前に「モデル」を整える

  • 学ぶこと📚

    • Entity:同一性(ID)で追う🪪
    • ValueObject:値そのもの(住所・金額など)💎
  • やってみよう🛠️:OrderId / Money / Address を軽く設計してみる🧩

  • チェック✅:値オブジェクトは不変にするとバグ減りがち🔒


第12章 不変条件(Invariants)の置き方🔐✨

  • ねらい🎯:「壊れた状態」を作れないようにする

  • 学ぶこと📚

    • 入口で守る(生成・更新メソッド)🚪
    • 例:合計金額がマイナスはNG🙅‍♀️
  • やってみよう🛠️:Orderの生成時チェック項目を3つ決める✅

  • チェック✅:不変条件をifで散らさず、中心に寄せる


第13章 集約(Aggregate)と“更新の入口”🚪🧺

  • ねらい🎯:イベントを「どこで起こすか」を決める土台

  • 学ぶこと📚

    • 集約ルート経由で更新するルール🧭
  • やってみよう🛠️:Orderが集約ルート、LineItemは内側、など決める📝

  • チェック✅:外から内側を直接いじらない


第14章 ドメインイベントの正体:起きた事実を表す🔔🕒

  • ねらい🎯:定義を一言で言えるようにする

  • 学ぶこと📚

    • OrderPaid / OrderPlaced などの“事実”📣
  • やってみよう🛠️:例題のイベント候補を5つ出す💡

  • チェック✅:イベントは「通知のため」じゃなく「事実の表現」


第15章 イベント名の付け方:過去形 + ドメイン語彙📝✨

  • ねらい🎯:読みやすく、ズレない命名にする

  • 学ぶこと📚

    • 〇〇Completed / 〇〇Failed の使い分け🙂
  • やってみよう🛠️:悪い例→良い例に直すリライト練習✍️

  • チェック✅:技術用語で命名しない(SavedToDb とか)🙅‍♀️


第16章 イベントの粒度:細かすぎ問題を避ける🔎🧠

  • ねらい🎯:イベント乱発を防ぐ

  • 学ぶこと📚

    • “業務的に意味のある単位”で切る🎯
  • やってみよう🛠️:「ユーザー的に意味がある?」で判定してみる🙂

  • チェック✅:迷ったら少なめ(KISS)🧼


第17章 イベントの中身(ペイロード)設計📦✨

  • ねらい🎯:必要最小限で安全なイベントにする

  • 学ぶこと📚

    • 入れる:集約ID、発生時刻、重要な値(必要なら)🧾
    • 入れない:DbContext、HTTP、巨大なモデル丸ごと🙅‍♀️
  • やってみよう🛠️:OrderPaidに入れる情報を3つに絞る✂️

  • チェック✅:イベントが太りすぎると依存が増える🐘💦


第18章 どこでイベントを発生させる?(集約ルート)❤️🔔

  • ねらい🎯:発生場所を固定して迷子を防ぐ

  • 学ぶこと📚

    • 「不変条件を守って状態が変わった」瞬間にイベント🌱
  • やってみよう🛠️:Order.MarkAsPaid() でイベントを起こす設計にする🧩

  • チェック✅:UI層でイベントを作らない🙅‍♀️


第19章 パターン①:ドメイン内にイベントを“溜める”📮🧺

  • ねらい🎯:まず一番シンプルな形を作る

  • 学ぶこと📚

    • DomainEvents コレクションという考え方🧺
  • やってみよう🛠️:イベント追加→後で回収、の流れ図を書く🗺️

  • チェック✅:配ったらクリア(掃除)🧹


第20章 パターン②:インプロセス・ディスパッチャ入門🏠📣

  • ねらい🎯:まず同一プロセス内で配信できる

  • 学ぶこと📚

    • Dispatcher の役割:イベントをハンドラへ渡す📦➡️🎯
  • やってみよう🛠️:Dispatcherのインターフェース案を作る🧩

  • チェック✅:ドメイン層は“配り方の詳細”を知らない


第21章 DI(依存性注入)超入門:ハンドラを差し替える🧱✨

  • ねらい🎯:ハンドラを増やしても壊れにくくする

  • 学ぶこと📚

    • コンストラクタ注入の感覚🧩
  • やってみよう🛠️:OrderPaidHandlerを登録→実行まで通す🏁

  • チェック✅:new で握りつぶさない(差し替え不可になる)🙅‍♀️


第22章 ハンドラ設計:1ハンドラ=1責務🎯🌸

  • ねらい🎯:読みやすく、増やしやすくする

  • 学ぶこと📚

    • 例:メール送信📧、ポイント付与🎁、ログ記録🧾 は分ける
  • やってみよう🛠️:OrderPaidでやりたいことを3つに分解🧩

  • チェック✅:巨大ハンドラは“第2の巨大メソッド”😵‍💫


第23章 同期と非同期:まず同期でOK、その後に発展🔁🙂

  • ねらい🎯:段階的に学ぶ(いきなり難しくしない)

  • 学ぶこと📚

    • 同期:すぐ実行(学習向き)🏠
    • 非同期:後で実行(運用向き)📨
  • やってみよう🛠️:同期で完成→非同期にしたら何が変わるか整理📝

  • チェック✅:非同期は“失敗と重複”がついてくる⚠️


第24章 例外と失敗の考え方:主処理と付随処理を分ける💥🧠

  • ねらい🎯:失敗時の判断で迷子にならない

  • 学ぶこと📚

    • 主処理(注文確定など)✅
    • 付随処理(メールなど)📧
  • やってみよう🛠️:「メール失敗で注文は失敗扱い?」をケースで考える🧩

  • チェック✅:全部を例外で巻き戻さない(業務次第)🙂


第25章 エラーモデリング超入口:リトライ可否を決める🔁🧯

  • ねらい🎯:運用で困らない最小ルールを持つ

  • 学ぶこと📚

    • 一時的エラー(ネットワーク)🌧️
    • 恒久的エラー(入力不正)🧱
  • やってみよう🛠️:ハンドラ失敗のログ項目を決める🧾

  • チェック✅:「何回」「いつまで」リトライするか方針が必要


第26章 観測(オブザーバビリティ)最小セット🔭✨

  • ねらい🎯:「あとで追える」を作る

  • 学ぶこと📚

    • イベント名、集約ID、結果、エラー理由🧾
    • 相関ID(この一連の処理のID)🧵
  • やってみよう🛠️:ログのテンプレ項目を作る📋

  • チェック✅:成功ログも残す(“静かに壊れる”防止)🙂


第27章 テスト①:ドメインの単体テスト(イベント発生を確認)🧪🔔

  • ねらい🎯:ドメインイベントが“仕様”になる体験をする

  • 学ぶこと📚

    • 状態変更→イベントが追加される✅
  • やってみよう🛠️:MarkAsPaidしたらOrderPaidが入るテストを書く✍️

  • チェック✅:I/Oなしで速く回るのがポイント🏃‍♀️💨


第28章 テスト②:ハンドラ単体テスト(外部I/Oは差し替え)🎭🧪

  • ねらい🎯:通知や連携を安全に検証

  • 学ぶこと📚

    • メール送信などはインターフェースでモック化📧🧩
  • やってみよう🛠️:フェイクSenderで「送ったか」を検証✅

  • チェック✅:テストが外部サービスに依存しない


第29章 テスト③:統合テスト(DI構成で通し確認)🧩🏁

  • ねらい🎯:配信ルートがつながっていることを確認

  • 学ぶこと📚

    • DI登録ミス・配信漏れを見つける🔎
  • やってみよう🛠️:最小E2E(注文→支払い→イベント→ハンドラ)を通す🛒🔔

  • チェック✅:統合は“少数の重要ケース”に絞る🙂


第30章 なぜ永続化が必要になる?(取りこぼし問題)😱📦

  • ねらい🎯:運用の現実を知る

  • 学ぶこと📚

    • アプリ停止でイベントが消える問題💥
    • DB保存成功✅なのに送信失敗❌というズレ
  • やってみよう🛠️:ズレ事故のシナリオを紙に描く📝

  • チェック✅:“確実に届けたい”が出たら次へ


第31章 Outbox入門:DBに書いて後で送る🗃️🚚

  • ねらい🎯:ズレを減らす定番パターンを理解

  • 学ぶこと📚

    • Outboxテーブルの役割📦
    • 未送信を拾う送信プロセス(バッチ/ホストサービス等)🔁
  • やってみよう🛠️

    • Outboxの列案(Id/Type/Payload/OccurredAt/ProcessedAt)を決める🧾
  • チェック✅:送信後のマーク、再送、監視もセット🙂


第32章 外部公開と次の一歩:統合イベント・ACL・契約・Sagaの入口🌍📜🔗

  • ねらい🎯:ドメインイベントを“広げる時”の注意点を知る

  • 学ぶこと📚

    • ドメインイベント(内部)❤️ vs 統合イベント(外部向け契約)📜
    • ACL(翻訳層)で外部の歪みを守る🧼
    • Sagaは「複数ステップの補償」を扱う考え方の入口♻️
  • やってみよう🛠️

    • OrderPaid(内部)→ OrderPaymentCompleted(外部向け)みたいに変換案を作る🧩
  • チェック✅

    • 外に出すなら“契約”として壊さず進化させるルールが必要✅