Skip to main content
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#版

第25章：卒業🎓✨ テスタブル設計の最小まとめ＆次の一歩 🚀💖

ここまで来たあなた、もう 「I/O境界の分離」できる人 です🥳💐 この章は「忘れないための最小まとめ」＋「次に伸びる道」をギュッとまとめるよ〜😊🧡

0) この章のゴール 🎯✨​

  • 迷ったときに戻れる 最小の合言葉 を持つ📌🧠
  • やりすぎ（抽象化しすぎ） を避けるコツを知る⚠️🙂
  • 次に進むなら何を学べば強いか、道筋が見える🌈🚶‍♀️

1) 卒業の合言葉（最重要）📦➡️🌍​

testable_cs_study_025_graduation.png

✅ I/Oは外へ、ルールは中へ​

  • 中：ビジネスルール・判断・計算（＝ピュア寄り）🌿
  • 外：DB/ファイル/HTTP/時刻/乱数/UI（＝現実世界）🌍🔌

これを守ると…

  • テストが 速い⚡
  • 変更が 怖くない🛡️
  • バグが 再現しやすい🎯

2) 3つの箱で考えると一生迷わない 📦📦📦✨​

イメージはこれだけでOK😊

  • ① ルール箱（ドメイン）：純粋ロジック🌿
  • ② 手順箱（ユースケース）：「どう進める？」の組み立て🧩
  • ③ 現実箱（I/Oアダプタ）：DB/HTTP/ファイル等を実行🔌

ポイントはね👇

  • ①②は 外の都合を知らない 🙅‍♀️🌍
  • ③は 実行担当（ここは汚れてOK）🧤🧼
  • つなぐのは 最後に1回だけ（Composition Root）🏗️✨

3) 卒業テンプレ（最小構成）🧰✨​

「これだけ守れば勝ち」っていう型を置いておくね😊💕

📁 フォルダ例（超ざっくり）​

  • Domain/（ルール）🌿
  • Application/（ユースケース）🧩
  • Ports/（I/Oの入り口＝interface）🚪
  • Adapters/（本物I/O実装）🔌
  • Program.cs（全部つなぐ場所）🏗️

「つなぐ場所」だけは特別：Program.cs 🏗️✨​

  • ここに new が集まるのが正解🙆‍♀️
  • “本物を接続する” のはここだけに寄せる📍

（例：イメージだけの最小スケルトン）👇

// Program.cs（つなぐ場所のイメージ）
services.AddSingleton<IClock, SystemClock>();
services.AddSingleton<IRandom, SystemRandom>();
services.AddScoped<ICouponRepository, SqlCouponRepository>();

services.AddScoped<IssueCouponUseCase>();

4) 卒業チェックリスト ✅🎓（ここ全部YESなら超強い！）​

✅ 設計チェック​

  • 重要ロジックの中に DateTime.Now / Random / File / HttpClient / DB直アクセスが 入ってない 🧼✨
  • 重要ロジックは 引数が揃えば結果が決まる（ピュア寄り）🌿🎯
  • 依存（I/O）は コンストラクタで受け取っている ✉️
  • new が散らばってなくて、だいたい 1箇所に寄ってる 🏗️

✅ テストチェック​

  • 単体テストが 速い（秒で終わる）⚡
  • Fake/Stubで「外」を差し替えられる🎭
  • テストが「たまに落ちる」みたいな 運ゲー じゃない🎲🙅‍♀️

5) よくある落とし穴（卒業後にハマりがち）⚠️😵‍💫​

落とし穴①：抽象化しすぎ（インターフェース作りすぎ）🧩🧩🧩​

  • 何でも IWhatever にすると、逆に読みづらい😇 回避：
  • 「外の世界（I/O）」だけ包む、から始めるのが安定👍✨
  • 迷ったら “テストで差し替えたい？” で判断💡

落とし穴②：Mock地獄👻（呼ばれた回数テストばかり）​

  • “実装の形” をテストしてしまうと、リファクタで壊れやすい💥 回避：
  • まずは Fake/Stub中心 🎭
  • “結果” を見るテストを増やす🎯

落とし穴③：Repositoryが「なんでも屋」になる🗄️🍱​

  • 取得も保存も検索も集計も…全部突っ込むと肥大化🐘 回避：
  • 「ユースケースが欲しい形」で小さく始める✂️
  • 増えたら分割すればOK（最初から完璧にしない）😊

落とし穴④：例外がどこで握られてるか迷子🚨🌀​

  • ルール違反とI/O失敗が混ざるとつらい😵 回避：
  • ルール違反：内側で判断（Resultっぽく返すなど）📦
  • I/O失敗：外側で扱う（リトライ/ログ/ユーザー表示）🌍

6) 次の一歩 🌉✨（どれから行ってもOK！）​

ここからは「伸び方」を3ルートに分けるね😊🛣️

ルートA：DIをちゃんと使えるようになる 💉✨​

  • ライフタイム（Singleton/Scoped/Transient）を体で覚える🧠
  • 「設定」「ログ」「HTTPクライアント」の扱いが一気にラクになる🪄

ルートB：クリーン/ヘキサゴナルへの橋渡し 🏰🔁​

  • 今やってることはまさに Ports & Adapters の入口だよ✨
  • 「内側（ルール）を守る」設計が、チーム開発でめちゃ効く🛡️

ルートC：テストを“現場レベル”に上げる 🧪🚀​

  • 単体：速くて大量に回す⚡
  • 結合：本物DB/本物HTTPは 少なめ にする🤏
  • CIで自動化：壊れたら即わかる🔔

7) 卒業課題（ミニアプリ案）🎮💖​

「1〜2日で作れて、境界が気持ちよく分かれる」やつ✨

案①：クーポン発行システム 🎫🎲🕰️​

  • 期限：時刻I/O🕰️
  • コード生成：乱数I/O🎲
  • 保存：DB/ファイルI/O🗄️🗂️
  • 発行ルール：内側📦✨

やること

  1. ルール（割引率、期限チェック）をピュアにする🌿
  2. IClock と IRandom と IRepository を作る🚪
  3. 単体テストは Fake で全部回す🎭🧪
  4. 最後に本物I/Oを繋いで動かす🏗️🚀

8) AI（Copilot/Codex）を卒業後にこう使う 🤖✅​

「AIに丸投げ」じゃなくて、設計を守るための相棒 にする感じ😊🫶

使えるお願いテンプレ 📝✨​

  • 「このクラス、I/Oが混ざってない？混ざってたら境界案を出して」🔍
  • 「このユースケースを単体テストしたい。Fake/Stub案とテストケースを列挙して」🧪
  • 「newが散らばってる。Composition Rootに寄せるリファクタ手順を出して」🏗️
  • 「Mockを減らしたい。結果を見るテストに置き換える案を出して」🎯

9) 最新の“土台”メモ（2026/01/16時点）🧾✨​

  • .NET 10 はLTSで、3年間サポート（〜2028年11月頃）として案内されています。(Microsoft for Developers)
  • C# 14 が最新リリースで、.NET 10 上でサポートされています。(Microsoft Learn)
  • Visual Studio 2022 は Current チャネルで 17.14.24（2026-01-13） が案内されています。(Microsoft Learn)
  • Visual Studio 2026 も 2026年1月の更新（18.2.0 / 2026-01-13）が案内されています。(Microsoft Learn)

まとめ 🎓💖​

  • 迷ったらこれだけ：I/Oは外へ、ルールは中へ 📦➡️🌍
  • やりすぎ注意：抽象化はI/Oから、Mockは増やしすぎない🎭⚠️
  • 次は「DIの理解」「クリーン/ヘキサゴナル」「結合テスト＆CI」のどれかへ🚀✨

ここまで積み上げたの、ほんとに強いよ〜🥳🎉 次は「卒業課題」みたいな小さいアプリを1本作ると、理解がガチで定着するよ🫶💖