メインコンテンツまでスキップ
KISS C#版YAGNI C#版SoC C#版ADR C#版HC/LC C#版DRY C#版Refactoring C#版テスト容易な設計 C#版TDD C#版エラーモデリング C#版レイヤー C#版MVC C#版依存関係ルール C#版DIP C#版DI C#版Is-a/Has-a C#版SOLID C#版GoF C#版Observer C#版CQS C#版状態機械 C#版不変条件 C#版Entity/VO C#版DDD C#版集約と境界 C#版ドメインイベント C#版モジュラーモノリス C#版ヘキサゴナル C#版クリーンアーキ C#版ACL C#版API Contract CSSemVer C#版DbC C#版冪等性 C#版CAPの肌感覚 C#版Outbox C#版Saga C#版CQRS C#版ES C#版境界づけられたコンテキスト C#版

ドメインイベント（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（外部向け）みたいに変換案を作る🧩

  • チェック✅

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