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

レイヤードアーキテクチャ（TypeScript版）詳細アウトライン：全20章 🏗️✨

対象：TypeScript初級〜中級／レイヤード初めて／設計超入門者😊 環境：Windows＋VS Code＋Copilot/Codex等あり🤖💡

第1章：ごちゃ混ぜ地獄から脱出しよう😵‍💫➡️😊​

  • ねらい🎯：レイヤードが必要な“痛み”を体感する

  • 学ぶこと📚

    • UI/HTTP/DB/型が混ざると何が起きる？💥
    • 「変更が怖い」「テストできない」「どこ直すの？」問題

  • ミニ演習🧩：ごちゃ混ぜコードの“困りポイント探し”🔎

  • AI活用🤖：コードを貼って「責務が混ざってる箇所」を指摘してもらう

  • チェック✅：混ざってる理由を言葉にできた？

第2章：TypeScriptで設計するときの“3つの軸”🧭✨​

  • ねらい🎯：TS特有の注意点を先に押さえる

  • 学ぶこと📚

    • 型（compile時）と検証（run時）は別もの⚠️
    • importの依存が設計を壊しやすい📦
    • any は最終兵器（できれば封印）😇

  • 演習🧩：「型だけあるのに壊れる例」をイメージする

  • AI活用🤖：any/曖昧型の置き換え候補を提案してもらう

  • チェック✅：型と実行時検証の違いが説明できる？

第3章：レイヤードの地図を作る🗺️🧱​

  • ねらい🎯：4層の役割を“言葉で”決める

  • 学ぶこと📚

    • Presentation：入力受付・表示・HTTP/画面イベント🎛️
    • Application：ユースケース（手順・調整）🎮
    • Domain：ルールと概念（核）💎
    • Infrastructure：DB/外部APIなど“外側の都合”🚪

  • 演習🧩：題材（ToDo等）を各層に仕分けしてみる

  • AI活用🤖：機能説明を渡して「各層に置くべき候補」を出してもらう

  • チェック✅：各層が“やらないこと”も言える？

第4章：依存の向きを固定する（import事故を防ぐ）➡️🚧​

  • ねらい🎯：レイヤード崩壊の一番の原因を先に封じる

  • 学ぶこと📚

    • 依存ルール：外側→内側はOK、内側→外側はNG🙅‍♀️
    • 「DomainがDBをimportしちゃった」事故💥
    • “禁止importの例”と“OKな例”を理解

  • 演習🧩：依存ルール表（OK/NG表）を作る✅

  • AI活用🤖：リポジトリ構成を渡して「違反importを推理」してもらう

  • チェック✅：なぜその依存がNGか説明できる？

第5章：VS Code＋2026 TSの土台づくり🛠️✨​

  • ねらい🎯：学習が進む“安全な環境”を用意する

  • 学ぶこと📚

    • strict寄りの設定で「早めに気づく」🔒
    • フォーマット＆Lintで“揉めない”🧼
    • パス別名（読みやすいimport）🧵

  • 演習🧩：最小のテンプレ構成を作る

  • AI活用🤖：設定ファイルの意図を説明してもらう（理解チェック）

  • チェック✅：strictのメリットを言える？

第6章：題材を決めて、最小要件でスタート🌱😊​

  • ねらい🎯：YAGNIで“盛りすぎ”防止

  • 学ぶこと📚

    • 題材例：ToDo／読書ログ／推し活支出メモ📚💸
    • 最小要件：追加・一覧・完了（まずこれだけ）👌
    • 受け入れ条件（できた判定）✅

  • 演習🧩：ユーザーストーリーを3つだけ書く✍️

  • AI活用🤖：要件を渡して「分けるべき責務」を提案してもらう

  • チェック✅：要件が増えそうになったら止められる？

第7章：Domain入門① “不変条件”を型で守る🔒💎​

  • ねらい🎯：壊れない中心（ドメイン）を作る

  • 学ぶこと📚

    • 不変条件：空はダメ、範囲外はダメ、矛盾はダメ🙅‍♀️
    • “作るときに検証して固定する”発想✨
    • readonly や “生成関数”の感覚

  • 演習🧩：タイトル空禁止、金額マイナス禁止などを設計

  • AI活用🤖：不変条件の漏れを列挙してもらう

  • チェック✅：“無効な状態を作れない”って言える？

第8章：Domain入門② Entity/ValueObject をやさしく分ける🎀​

  • ねらい🎯：バグりやすい値を“固める”

  • 学ぶこと📚

    • Entity：IDで追う（ToDoItemなど）🪪
    • ValueObject：値そのもの（Money/Periodなど）💰📅
    • どこにルールを書くと読みやすい？📖

  • 演習🧩：VO候補を3つ見つけるゲーム🎮

  • AI活用🤖：DTO化しがちな設計を“VO化”案として出してもらう

  • チェック✅：VOを作るメリットが言える？

第9章：Domain入門③ 状態と遷移をキレイにする🔁✨​

  • ねらい🎯：業務フローの抜け漏れを減らす

  • 学ぶこと📚

    • 状態（例：未完了/完了）と許可される操作
    • “できない操作”を明示する（早めに止める）🛑

  • 演習🧩：状態遷移表を1枚作る🗒️

  • AI活用🤖：遷移の抜け漏れチェックを依頼

  • チェック✅：禁止遷移を説明できる？

第10章：Application入門① ユースケース（手順書）を作る🎮📋​

  • ねらい🎯：操作の入口を整理する

  • 学ぶこと📚

    • ユースケース＝「何をしたい？」の単位
    • Command/Queryの気持ち（更新と参照を混ぜない）🔁
    • Domainを呼ぶ順番・結果のまとめ

  • 演習🧩：「ToDoを追加する」「一覧を見る」をユースケースにする

  • AI活用🤖：ユースケース名の命名案を出してもらう

  • チェック✅：Domainに手順を書かない理由が言える？

第11章：Application入門② DTOと境界変換（Mapping）🧩📦​

  • ねらい🎯：“画面/HTTP都合”をDomainに持ち込まない

  • 学ぶこと📚

    • 入力DTO／出力DTO／Domainモデルは別物🙂
    • 変換をどこに置く？（境界でやる）🚪
    • “変換だらけで迷子”を防ぐ整理術🧹

  • 演習🧩：入力DTO→Domain→出力DTOの流れを図にする🗺️

  • AI活用🤖：変換が肥大化してないかレビューしてもらう

  • チェック✅：DTOとDomainを混ぜない自信ある？

第12章：Port（interface）で依存を逆転する🔌➡️✨​

  • ねらい🎯：DBや外部APIに引きずられない中心を作る

  • 学ぶこと📚

    • Repositoryや外部サービスを interface として定義
    • Applicationは「抽象」を呼ぶ（DIPの入口）
    • interfaceの責務を小さく保つコツ✂️

  • 演習🧩：保存用interfaceを1つ作る（読み/書き最小）

  • AI活用🤖：interfaceが大きすぎないかチェック

  • チェック✅：「実装は外側」の意味を言える？

第13章：Infrastructure入門① 永続化（DB/Storage）を外側に閉じ込める🗄️🚪​

  • ねらい🎯：保存方法が変わっても中心が壊れない

  • 学ぶこと📚

    • DB/Storageは詳細、Domainは知らない🙈
    • Repository実装で吸収する📦
    • “保存形式”と“ドメイン”の変換ポイント

  • 演習🧩：インメモリ実装→DB実装に差し替える想像🔁

  • AI活用🤖：永続化の責務が漏れてないか確認

  • チェック✅：どこまでがInfrastructureの責務？

第14章：Infrastructure入門② 外部APIを“翻訳”する📡🈂️​

  • ねらい🎯：外部のクセをDomainに入れない

  • 学ぶこと📚

    • 外部DTO⇔Domain型の翻訳（ACLっぽい考え）
    • タイムアウト、失敗、リトライの扱いの基本⏱️
    • 設定値（APIキー等）の扱い🔐

  • 演習🧩：外部レスポンス→Domainへの変換ルールを書く

  • AI活用🤖：失敗ケースを網羅してもらう

  • チェック✅：外部都合をDomainに混ぜてない？

第15章：Composition Root（組み立て場所）を決める🏗️🧩​

  • ねらい🎯：依存の組み立てを迷子にしない

  • 学ぶこと📚

    • どこで実装を差す？（入口でまとめて組む）
    • “どこでもnew/生成”をやめる
    • DIコンテナは“必要になってから”でもOK😊

  • 演習🧩：依存の配線図を描く🧵

  • AI活用🤖：配線が循環してないかチェックしてもらう

  • チェック✅：組み立て場所が1つに集まってる？

第16章：Presentation層（HTTP/画面）を薄くする🎛️✨​

  • ねらい🎯：UIが太るのを防ぐ（Controller肥大化防止）

  • 学ぶこと📚

    • 入力→検証→ユースケース呼ぶ→結果返す、だけ👍
    • 表示用の整形はPresentationの責務
    • エラー表示の作法（ユーザーに優しく）💌

  • 演習🧩：ハンドラを“薄くする”リファクタ

  • AI活用🤖：「この処理、Applicationに移す？」相談

  • チェック✅：Presentationがビジネスルールを持ってない？

第17章：入力バリデーション（実行時チェック）🛡️✅​

  • ねらい🎯：型だけでは守れない世界を守る

  • 学ぶこと📚

    • 入力は信用しない（HTTP/フォーム）😇
    • Presentationで弾く／Domainで弾くの線引き🧱
    • “エラーメッセージの設計”もここで

  • 演習🧩：無効入力のパターン表を作る📋

  • AI活用🤖：バリデーション漏れチェック

  • チェック✅：境界で守る意識ができた？

第18章：エラー設計（例外地獄を卒業）⚠️🌤️​

  • ねらい🎯：壊れ方を“仕様”にする

  • 学ぶこと📚

    • Domainエラー／インフラエラー／想定外を分ける🧩
    • どこで握る？どこで変換する？🤝
    • ユースケースの戻し方（成功/失敗の表現）

  • 演習🧩：代表エラーを分類する（表を作る）🗂️

  • AI活用🤖：分類の妥当性レビュー

  • チェック✅：例外を投げっぱなしにしてない？

第19章：テスト設計（レイヤードのご褒美🍰）🧪✨​

  • ねらい🎯：1人開発でも品質を落とさない

  • 学ぶこと📚

    • Domain：ユニットテストが最強に書きやすい💎
    • Application：fake/mockでユースケース検証🧸
    • Infrastructure：統合テストは“少数精鋭”🔧

  • 演習🧩：テストピラミッドを自分の言葉で描く🗺️

  • AI活用🤖：テスト観点の漏れを洗い出す

  • チェック✅：どの層をどのテストで守るか言える？

第20章：運用＆成長（壊れない仕組みづくり）🌱🏗️🤖​

  • ねらい🎯：プロジェクトが大きくなっても崩れない

  • 学ぶこと📚

    • 依存ルールを自動で守る（lint/CIの発想）🏰
    • 観測の最小セット（ログ、相関ID、重要イベント）📈🪵
    • モジュール分割の入口（機能で区切る/境界を守る）🧩
    • AI活用の型：設計レビュー、違反検出、リファクタ提案🤖✨

  • 演習🧩：運用チェックリストを作る✅

  • AI活用🤖：PRレビューの観点テンプレを作ってもらう

  • チェック✅：守る仕組み（自動化）を1つ入れられる？