メインコンテンツまでスキップ
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#版

アウトボックス（Outbox）教育コンテンツ：22章 詳細アウトライン 📚✨

第1章：まず「Outboxって何のため？」を超ざっくり掴む 😺📦​

  • 今日のゴール：DB更新と通知送信のズレをなくすイメージを持つ✨
  • ありがちな事故（例：注文は保存されたのにメールは飛ばない）😱
  • 「Outbox＝あとで送るための“発送待ち箱”」という比喩📮

第2章：なぜズレるの？二重書き込み（Dual Write）の怖さ 😵‍💫🧨​

  • DB保存と送信（HTTP/Queue）が“別世界”な理由🌍
  • 失敗パターン表（DB成功・送信失敗／逆／タイムアウト…）⛈️
  • “成功したと思ったのに実は失敗”が起きる理由🌀

第3章：開発環境セットアップ（Windows）🪟🧰​

  • Visual Studio での作り方（ソリューション、プロジェクト）🧩
  • Visual Studio Code でもできる構成（必要なら）⌨️
  • 2026想定の .NET / C# でプロジェクト開始まで🏁

第4章：AI（Copilot/Codex系）を“安全に使う”流れ 🤖✅​

  • 何をAIに頼む？（雛形・テスト案・例外パターン洗い出し）✨
  • 何は人間が必ず見る？（トランザクション範囲、再試行、冪等性）👀
  • レビュー用チェックリスト（この教材で毎回使う）📝
  • ※組織名：GitHub / OpenAI / Microsoft（利用環境の前提として1回だけ登場）

第5章：トランザクション超入門（“全部成功 or 全部失敗”）🔒🍙​

  • コミット/ロールバックの感覚をつかむ🎮
  • 「同じトランザクションに入れる」ってどういうこと？🧠
  • やらかし例：トランザクションが短すぎ／長すぎ問題😅

第6章：イベントとメッセージの超入門 📩✨​

  • 「イベント（起きた事実）」と「命令（して）」の違い🗣️
  • “通知”はだいたいメッセージとして飛ぶ📨
  • 送信先（キュー／イベント基盤／HTTP）のイメージだけ持つ🎯

第7章：Outboxパターンの全体像（登場人物紹介）🗺️👥​

  • 主役：業務テーブル、Outboxテーブル、配送係（Relay）🚚
  • 流れ：①業務更新＋Outbox記録（同じトランザクション）→②後で配送📦➡️📩
  • 何が嬉しい？：ズレが起きにくい🛡️

第8章：いつ使う？いつ使わない？判断のコツ 👀🌱​

  • 使う：他サービス連携、非同期通知、リトライ前提の世界🌩️
  • 使わない：単純な単一アプリ内で完結、送信不要🙅‍♀️
  • “小さく導入”の境界線（初心者が迷わない基準）📏

第9章：Outboxテーブル設計（ミニマム版）📦🧱​

  • 最小セット：Id / Type / Payload / OccurredAt 🧾
  • Statusは必要？（最初は“未送信/送信済”だけでもOK）✅
  • 演習：DBにOutboxテーブルだけ作って眺める👀

第10章：Outboxテーブル設計（運用を見据えた版）🔍🧹​

  • Status（Pending/Sent/Failed）、RetryCount、LastError…💥
  • 取り出し用インデックス（“未送信を素早く探す”）🏃‍♀️
  • 保持期間（古いOutboxを掃除する）🧹
  • “後で地獄”にならない設計のコツ🔥

第11章：書き込み側の設計（責務分離の形）🧠🧩​

  • 「業務処理」と「Outboxに積む」を混ぜない（SoC）🍱
  • “イベントを作る場所”を決める（ユースケース層？ドメイン？）📌
  • まずはシンプルに：アプリ層でOutbox record生成📝

第12章：書き込み側の実装（C# + DB更新＋Outbox追加）✍️🔒​

  • 同一トランザクションで2つ書く（ここが本丸）👑
  • 例外時の動き：途中で落ちたらどうなる？🧯
  • AIに雛形を出させる→人が“トランザクション範囲”を最終確定🤖✅
  • ミニ演習：注文作成（Orders）＋Outbox追加を1回動かす🛒

第13章：Payload（中身）設計：JSON化とサイズ感 🧾📏​

  • Payloadに何を入れる？（必要最小限が正義）👼
  • 個人情報を詰めすぎない（運用・セキュリティ的にも）🙈
  • “参照IDだけ送る”設計の考え方🔗
  • ミニ演習：PayloadをJSONで保存して読めることを確認👀

第14章：契約（バージョン）をちょい意識する 🏷️🔁​

  • 将来、Payloadの形は変わる（絶対変わる）😇
  • Versionフィールド or Type名にv1/v2を付ける案📌
  • “壊さず進化”のミニルール（初心者版）🧡

第15章：配送係（Relay）の設計：まずはポーリングでOK ⏱️🚚​

  • ポーリングとは？（一定間隔で未送信を取りに行く）⏰
  • 1回に何件？（バッチサイズ）📦📦📦
  • 送信の順序をどう扱う？（最初は気にしすぎない）🙂

第16章：配送係（Relay）の実装：Worker/BackgroundService 🧑‍💻🔧​

  • Windows上で動かす「常駐の小さな配送アプリ」🪟
  • ループ、待機、キャンセル（停止）の基本🛑
  • “二重起動”が起きると何が困る？👯

第17章：送信先アダプタ設計（DIP/DIの練習）🔌🧩​

  • IEventPublisherみたいなインターフェースを切る✂️
  • 実装1：まずは“偽ブローカー”（コンソール出力）🖥️
  • 実装2：HTTP送信などに差し替えできる形にする🔁
  • DI（コンストラクタ注入）で差し替え練習🧃

第18章：到達保証の話（Outboxはだいたい“At-least-once”）📬🔁​

  • “最低1回は送る”＝重複が起き得る😅
  • 「送れたかどうか」は意外と曖昧問題🤷‍♀️
  • ここで次章の冪等性へつなぐ🧠✨

第19章：冪等性（考え方編）🧷🧠​

  • 「2回届いても1回分として扱う」って何？🔁➡️1️⃣
  • Idempotency Keyの考え方（OutboxIdを使うのが定番）🪪
  • “送り手”だけでなく“受け手”が守るのが基本🤝

第20章：冪等性（実装編）：受け手側の重複排除 ✅🛡️​

  • 方法A：処理済みテーブル（Inbox的なもの）📥
  • 方法B：ユニーク制約で二重登録を弾く🧱
  • ミニ演習：同じメッセージを2回処理しても結果が1回になるのを確認🎯

第21章：リトライ設計＋デッドレター（失敗と仲良くなる）🛠️🧯​

  • 一時失敗（ネットワーク） vs 恒久失敗（不正データ）🌩️🧱
  • リトライ回数、間隔、バックオフ（だんだん待つ）⏳
  • “毒メッセージ”は隔離（Dead Letter相当）☠️➡️📦
  • 運用のミニ手順：隔離したら何を見る？どう直す？🔍

第22章：観測＆テスト＆ミニ演習まとめ（ここで完成！）📈🧪🏁​

  • 観測：未送信数、滞留時間、失敗率、LastErrorを見る👀📊

  • ログの最低限（相関ID、OutboxId、例外理由）🧵

  • テスト戦略

    • 単体：Outboxレコード生成の正しさ🧪
    • 統合：DB更新＋Outbox追加が同時に成功する🔒
    • 失敗注入：送信失敗→リトライ→成功🎭

  • 最終ミニ演習：

    • 「注文作成→Outbox→Relay→送信（偽ブローカー）→受け手で冪等」まで通す🛒📦🚚📩✅

  • 次の一歩：最終的整合性、Saga、観測強化へ🧭✨