メインコンテンツまでスキップ

クリーンアーキテクチャ（TypeScript）45章 詳細アウトライン 🏛️✨

前提はずっと同じだよ🪟🧩

  • Windows / VS Code
  • TypeScript（2026年の最新前提）
  • Copilot / Codex系AI拡張が使える🤖✨
  • 題材：超ミニ Taskアプリ（Create / Complete / List）🗒️

Part 1：核をつかむ（1〜7）🧭​

第1章：なぜクリーンアーキ？（ゴールを固定）🎯​

  • ねらい：この講座の「勝ち筋」を最初に決める😊
  • 学ぶ：変更に強い＝どこが強くなる？／テストが楽になる理由
  • つくる：設計ゴール1枚メモ（例：中心を汚さない、差し替えできる）
  • AI相棒🤖：「この講座のゴールを“初心者向けに3行”でまとめて」

第2章：4つの円（4層）の役割を短文で言えるようにする🟡🟠🔵⚫​

  • ねらい：4層の責務を“迷わない言葉”にする
  • 学ぶ：Entities / Use Cases / Interface Adapters / Frameworks & Drivers
  • つくる：層ごとの「置くもの／置かないもの」一覧📌
  • AI相棒🤖：「各層に置くものを3つずつ、例で」

第3章：Dependency Rule（依存の向き）が全て⬅️💘​

  • ねらい：内側が外側を知らない、を体に入れる
  • 学ぶ：importの向き＝設計の崩壊ポイント／依存逆転の意味（クリーンアーキ文脈で）
  • つくる：OK依存✅/NG依存❌の判定表
  • AI相棒🤖：「この依存関係、違反を指摘して修正案も」

第4章：Boundary（境界）ってなに？🚧​

  • ねらい：「混ぜない線」を自分で引けるようにする
  • 学ぶ：境界＝責務の切れ目／境界で変換が起きる
  • つくる：今回の境界（UI↔UseCase↔DB）宣言📍
  • AI相棒🤖：「この境界定義、混ざってるところを指摘して」

第5章：“データの流れ”でクリーンアーキを理解する📦​

  • ねらい：依存だけじゃなく、データの形も守る
  • 学ぶ：Request/Responseの設計／内側に便利な形で渡す感覚
  • つくる：CreateTaskの入出力スケッチ（文章＋矢印）✍️
  • AI相棒🤖：「CreateTaskの入出力を“境界を意識して”整理して」

第6章：内側の言葉／外側の言葉を分ける📖​

  • ねらい：HTTP/SQLの言葉を内側に持ち込まない
  • 学ぶ：命名の境界（内側＝業務、外側＝技術詳細）
  • つくる：内側用語ミニ辞書（Task/Completeなど）📝
  • AI相棒🤖：「この名前、内側向き？外側向き？改善案ちょうだい」

第7章：ユースケース一覧を確定（アプリの中心）🎬​

  • ねらい：迷子防止！まずUse Caseを固定
  • 学ぶ：ユースケース＝“目的”／粒度＝最小でOK
  • つくる：Create / Complete / List を1行仕様で確定✅
  • AI相棒🤖：「この3ユースケース、粒度が適切か判定して」

Part 2：Entities（中心のルール）を作る（8〜13）❤️​

第8章：Entities層の作り方（最小から）🌱​

  • ねらい：中心を作る、でも作り込みすぎない
  • 学ぶ：Entityが持つべきもの（状態＋ルール）だけに絞る
  • つくる：Taskの最小モデル（id/title/completed等）🧱
  • AI相棒🤖：「Taskに必要な属性を“最小”で提案して」

第9章：Entityの公開API設計（壊されない入口）🔒​

  • ねらい：外側から雑に書き換えさせない
  • 学ぶ：生成・更新をメソッドに寄せる／直接代入を減らす
  • つくる：create() / complete() などのAPI設計案
  • AI相棒🤖：「外から壊されないEntity API設計にして」

第10章：ルール違反の表現（内側の失敗）⚠️​

  • ねらい：失敗を“内側の言葉”で返す準備
  • 学ぶ：ドメイン的な失敗種類（例：InvalidTitle）
  • つくる：失敗型（ドメインエラー）定義📌
  • AI相棒🤖：「この仕様で起きる“内側の失敗”を列挙して」

第11章：Entityのライフサイクル（作る→変える）🔁​

  • ねらい：更新ルールの置き場を固定する
  • 学ぶ：完了処理の責務はEntity？UseCase？（境界の整理）
  • つくる：completeできる条件をEntity側に集約🛡️
  • AI相棒🤖：「completeの禁止条件、漏れを探して」

第12章：Entities層の“依存ゼロ”監査👀​

  • ねらい：中心が外に寄りかからないことを保証
  • 学ぶ：Entitiesが参照していいもの（標準機能・型など）だけ
  • つくる：Entities層のimportルール表✅
  • AI相棒🤖：「このimport、Entitiesに置いてOK？」

第13章：Entitiesの最小テスト（中心の安心感）🧪​

  • ねらい：中心ルールが壊れない状態を作る
  • 学ぶ：テストは速く小さく（中心のルールだけ）
  • つくる：生成・更新の基本テストケース✅
  • AI相棒🤖：「Entityテスト観点を5つ出して」

Part 3：Use Cases（アプリの方針）を作る（14〜23）🎬​

第14章：Use Case Interactorの型を決める📐​

  • ねらい：毎回迷わないテンプレを作る
  • 学ぶ：1目的=1UseCase／入力→処理→出力
  • つくる：Interactorの骨格（クラスでも関数でもOK）🧱
  • AI相棒🤖：「UseCaseのテンプレ構造を提案して」

第15章：Input Boundary：Requestモデル設計📥​

  • ねらい：外側入力を内側に入れる“整形口”
  • 学ぶ：Requestは外側依存を持たない（HTTPを入れない）
  • つくる：CreateTaskRequest / CompleteTaskRequest など
  • AI相棒🤖：「Requestに必要な項目だけ抽出して」

第16章：Output Boundary：Response設計📤​

  • ねらい：UseCaseが“表示都合”に縛られない
  • 学ぶ：Responseは内側基準（UI向けは後で整形）
  • つくる：CreateTaskResponse / ListTasksResponse 設計📦
  • AI相棒🤖：「Responseを“内側基準”で設計して」

第17章：UseCaseが依存するのはPortだけ🔌​

  • ねらい：DB/HTTPを直接触らない徹底
  • 学ぶ：UseCaseはインターフェース（Port）にだけ話す
  • つくる：UseCaseが必要なPort一覧メモ📝
  • AI相棒🤖：「このUseCaseが必要なPortを列挙して」

第18章：CreateTaskを実装（中心の流れを固める）✅​

  • ねらい：追加系UseCaseの基本形を完成させる
  • 学ぶ：入力→ルール→保存→出力
  • つくる：CreateTaskInteractor（Port前提）🧩
  • AI相棒🤖：「この手順で抜けてるチェックある？」

第19章：CompleteTaskを実装（更新系の基本形）🔁✅​

  • ねらい：状態更新の責務分離を保ったまま作る
  • 学ぶ：取得→Entity更新→保存→出力
  • つくる：CompleteTaskInteractor（Port前提）
  • AI相棒🤖：「更新系UseCaseの落とし穴を指摘して」

第20章：ListTasksを実装（参照系の基本形）👀✅​

  • ねらい：Query系の流れを確立する
  • 学ぶ：参照の結果を内側基準で返す
  • つくる：ListTasksInteractor（Port前提）
  • AI相棒🤖：「ListのResponseに必要な項目を提案して」

第21章：UseCaseの失敗を“境界で扱う”設計にする⚠️➡️🚧​

  • ねらい：内側の失敗を外側表現に混ぜない
  • 学ぶ：ドメイン失敗と技術失敗を分けて扱う前提
  • つくる：UseCase戻り値の方針（成功/失敗の表現を統一）📌
  • AI相棒🤖：「成功/失敗を扱う戻り値の形を提案して」

第22章：UseCaseテスト：Port差し替えで検証🧪🎭​

  • ねらい：外側なしで中心が検証できる！を体感
  • 学ぶ：Fake/StubでPortを置き換える
  • つくる：3UseCaseのテスト（成功＋失敗）✅
  • AI相棒🤖：「Fake Repositoryを簡単に作って」

第23章：UseCases層の依存監査（外側参照ゼロ）🛡️​

  • ねらい：長期的に崩れないための仕上げ
  • 学ぶ：UseCasesはEntitiesとPortsだけ参照
  • つくる：参照ルール（チェックリスト化）✅
  • AI相棒🤖：「UseCaseが外側参照してないか確認して」

Part 4：Ports（差し替え口）を最小で設計（24〜29）🔌​

第24章：Portって何？（内側が欲しい“能力”）🎯​

  • ねらい：外側都合じゃなく内側都合で決める
  • 学ぶ：能力の言語化（保存したい／取得したい）
  • つくる：Portの説明文（1Port=1能力）📝
  • AI相棒🤖：「この能力に合うPort名を10個」

第25章：Repository Port設計（最小メソッド主義）🗄️✨​

  • ねらい：巨大Repository化を防ぐ
  • 学ぶ：UseCaseから逆算して必要分だけ
  • つくる：TaskRepositoryのAPI確定✅
  • AI相棒🤖：「このメソッド、要る？要らない？理由つきで」

第26章：副作用Port（Clock/Idなど）の最小抽象⏰🆔​

  • ねらい：テストできる中心を守る
  • 学ぶ：時間・IDは“外側の都合”になりやすい
  • つくる：IdGenerator / Clock Port（必要分だけ）
  • AI相棒🤖：「Clock/IdをPort化する必要性を短く説明して」

第27章：Portの入出力モデル（内側基準で決める）📦​

  • ねらい：DB都合の型をPortに流し込まない
  • 学ぶ：Portは“内側に都合の良い形”でやりとり
  • つくる：Repositoryが返す型の方針（Entity/専用DTO）決定
  • AI相棒🤖：「Portの入出力が外側都合になってないかチェックして」

第28章：Portの境界線チェック（命名・責務）🧼​

  • ねらい：Portが“外側の技術用語”になってないか確認
  • 学ぶ：内側語彙で命名するコツ
  • つくる：Port命名・責務の再点検リスト✅
  • AI相棒🤖：「このPort名、技術寄り？業務寄り？直すなら？」

第29章：Portを増やしすぎない運用（必要になったら）🌱​

  • ねらい：抽象の乱立を防ぐ
  • 学ぶ：追加の判断基準（差し替えが必要か？テストか？）
  • つくる：Port追加ルール（短文で）📌
  • AI相棒🤖：「今このPortを作るべきか、判断して」

Part 5：Interface Adapters（変換して繋ぐ）を作る（30〜38）🔁🌐​

第30章：Inbound Adapter（Controller）は責務3つだけ🧻​

  • ねらい：入口は薄く！
  • 学ぶ：受け取る→変換→UseCase呼ぶ
  • つくる：3ユースケース分のController骨格🚪
  • AI相棒🤖：「Controllerを薄くする改善案を出して」

第31章：入力変換（HTTP→Request）を閉じ込める📥➡️📦​

  • ねらい：HTTPの癖を内側に持ち込まない
  • 学ぶ：バリデーションはどこで何をやるか（境界で整理）
  • つくる：変換関数（Request BuilderでもOK）
  • AI相棒🤖：「この入力をRequestに変換する関数を書いて」

第32章：Output Boundary：Presenter（出力変換口）を作る🎨​

  • ねらい：UseCaseを表示形式から守る
  • 学ぶ：Response→表示向けの整形はAdapter側
  • つくる：Presenterの入口（関数/クラスどちらでも）✨
  • AI相棒🤖：「ResponseからViewModelを作る設計案ちょうだい」

第33章：ViewModel設計（画面向けの形を固定）📦✨​

  • ねらい：UI変更が中心に波及しない
  • 学ぶ：ViewModelは外側都合OK（だからこそここに置く）
  • つくる：TaskViewModel（一覧向け）定義✅
  • AI相棒🤖：「一覧表示に必要なViewModel項目を提案して」

第34章：エラー変換（内側→外側の表現）⚠️➡️🌐​

  • ねらい：失敗の見せ方を境界に固定
  • 学ぶ：ドメイン失敗→HTTPステータス／メッセージの対応
  • つくる：変換テーブル（コード or 表）🧾
  • AI相棒🤖：「このドメインエラーをHTTPに変換する表を作って」

第35章：Outbound Adapter：InMemory Repository実装🧺✅​

  • ねらい：差し替えの第一歩を最速で体感
  • 学ぶ：Portを満たす実装＝Adapter
  • つくる：InMemoryTaskRepository
  • AI相棒🤖：「このinterfaceを満たす最小実装を書いて」

第36章：Outbound Adapter：永続化Repository（SQLite等）🗃️✅​

  • ねらい：「外側だけ変更して動く」を実演できるようにする
  • 学ぶ：DBドライバの詳細は外側へ
  • つくる：SQLiteTaskRepository（または同等の永続化実装）
  • AI相棒🤖：「DB永続化実装の注意点（トランザクション/例外）を整理して」

第37章：Mapper：DBレコード↔内側モデル変換を隔離🔄🧹​

  • ねらい：変換地獄を“ここだけ”に閉じ込める
  • 学ぶ：Record/RowとEntityのズレを吸収
  • つくる：TaskRecordMapper（命名自由）
  • AI相棒🤖：「Mapperの変換漏れが起きない設計にして」

第38章：Adapters層の依存監査（中心を汚さない）🛡️​

  • ねらい：Adapterが勝手に中心ルールを持たないようにする
  • 学ぶ：Adapters→UseCases/Entities参照のルール
  • つくる：Adaptersの参照チェックリスト✅
  • AI相棒🤖：「このAdapter、中心に責務が漏れてないか診断して」

Part 6：Frameworks & Drivers（外側に押し出す）39〜42 ⚙️🌍​

第39章：Webフレームワークは“外側”として置くだけ🧱​

  • ねらい：フレームワーク依存を中心に入れない
  • 学ぶ：ルーティングやミドルウェアは外側
  • つくる：Web起動・ルート定義の配置ルール📁
  • AI相棒🤖：「フレームワーク依存が中心に漏れない配置案を出して」

第40章：DBドライバ／接続設定は外側に隔離🗄️➡️🌍​

  • ねらい：DBの詳細を最後まで外に置く
  • 学ぶ：接続文字列・クライアント生成の置き場
  • つくる：DB接続の外側モジュール
  • AI相棒🤖：「接続設定が内側に漏れてないかチェックして」

第41章：設定（Config）の境界：どこで読み、どこへ渡す？🧾​

  • ねらい：環境依存を内側に持ち込まない
  • 学ぶ：外側で読み、必要最小限だけ内側へ注入
  • つくる：Configオブジェクトの受け渡し設計📌
  • AI相棒🤖：「Configを内側に入れすぎない設計に直して」

第42章：外部サービス（通知など）もDriverとして外側へ📣​

  • ねらい：外部APIをPort/Adapterで包む流れを完成させる
  • 学ぶ：Port定義→Adapter実装→注入
  • つくる：Notifier Adapter（ダミーでもOK）
  • AI相棒🤖：「外部サービス連携のAdapterを最小で作って」

Part 7：Composition Root（組み立て）で完成（43〜45）🏗️💉​

第43章：Composition Rootとは（依存を一箇所で組む）🧩​

  • ねらい：依存の迷子を終わらせる
  • 学ぶ：組み立て場所＝外側／中心はnewしない
  • つくる：依存の組み立て手順書（図でもOK）🗺️
  • AI相棒🤖：「このプロジェクトの依存ツリーを整理して」

第44章：手動DIで組み立て（まずはコンテナ無し）💉✨​

  • ねらい：依存が“見える状態”で理解を固める
  • 学ぶ：Repository/Clock/IdをUseCaseへ注入
  • つくる：起動コードで全結線（動くところまで）✅
  • AI相棒🤖：「組み立てコードを読みやすく整形して」

第45章：最終チェック：差し替え実演（外側を変えても中心が無傷）🎉🔁​

  • ねらい：クリーンアーキの価値を体で理解して卒業！
  • 学ぶ：InMemory↔SQLite差し替えで中心が変わらない理由
  • つくる：差し替えデモ＋テストが同じまま通る状態✅✨
  • AI相棒🤖：「差し替え手順と影響範囲を短くまとめて」

必要なら次は、この45章それぞれに

  • 🎯「到達目標（1文）」
  • ✅「理解チェック問題（1問）」
  • 📦「提出物（成果物）」
  • 🤖「AIプロンプトのテンプレ（コピペ用）」 を付けた“授業としてそのまま使える版”にもできるよ😊✨