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

1人開発者のためのDDD学習ロードマップ：全100章

「設計初心者」から「AIを使いこなす設計者」へ​

第1部：【そもそも設計とは何か？】なぜコードを書く前に考えるのか (1-10)​

「動けばいい」コードが、なぜ1ヶ月後のあなたを苦しめるのかを理解します。

  1. 「書ける」と「設計できる」は別物：C#が書けても設計で迷う理由
  2. 設計の唯一の目的は「変更」のため：一生変えないコードに設計はいらない
  3. 1人開発最大の敵は「記憶の風化」：未来の自分を「他人」だと思って書く
  4. コードの複雑さをAIに丸投げしてはいけない理由：AIは「部分」は得意だが「全体」は壊す
  5. 「スパゲッティコード」を解剖する：どこを直すとどこが壊れるか分からない恐怖
  6. 設計がないとAIへの指示がブレる：プロンプトが長くなるのは設計がない証拠
  7. 良い設計の指標「疎結合・高凝集」を世界一わかりやすく
  8. 「汚く書いて後で直す」が1人開発で失敗する理由
  9. AIを「コードを書く作業員」ではなく「設計の壁打ち相手」にする
  10. 【ワーク】：過去に自分が書いた「読みづらいコード」をAIに批評させてみる

第2部：【DDDの大きな枠組み】万能ではない「道具」の使い所 (11-20)​

DDDが何であり、何でないか。その「マッチング」をはっきりさせます。

  1. DDD（ドメイン駆動設計）の正体：プログラムを「現実の仕事」に似せること
  2. DDDがマッチする分野：複雑なルールがある（例：会計、ゲームの計算、予約システム）
  3. DDDがマッチしない分野：ただの記録帳（例：掲示板、単純なブログ、データ移行ツール）
  4. 「1人開発×DDD」の相性：コミュニケーション相手はAIと「未来の自分」
  5. 「AI使用前提」のDDD：定型コードはAIに、人間は「境界線」を引くことに集中する
  6. DDDの2つの顔：戦略（どう分けるか）と戦術（どう書くか）
  7. なぜ「DBから作ってはいけない」のか：テーブル構造に脳がハックされるのを防ぐ
  8. 人数規模の議論：1人なら「戦術」からつまみ食いしても十分効果がある
  9. DDDの学習コスト：最初は遅くなるが、ある地点から爆速になる曲線
  10. 【ワーク】：自分が作りたいアプリがDDDに向いているかAIと判定する

第3部：【戦略的設計】AIに「このアプリの正解」を教える (21-35)​

コードを書く前の「整理」のステップです。1人開発ではここがAIへの指示書になります。

  1. ドメイン（領域）を定義する：このアプリで一番「大事な場所」はどこか？
  2. 境界づけられたコンテキスト：1つのアプリの中に「小さな独立国」を作る
  3. 1人開発での境界線：フォルダ分け？ プロジェクト分け？ 実践的な基準
  4. ユビキタス言語（共通言語）：AIと会話するときの「単語帳」を作る
  5. AIにドメインエキスパートを演じさせる：仕様の矛盾をAIに指摘させる
  6. サブドメインの分類：コア（勝負所）、支援（補助）、汎用（外部任せ）
  7. 腐敗防止層 (ACL)：外部ライブラリをそのまま使わず、薄い皮を被せる
  8. コンテキストマップ：1人で作るアプリの全体図をAIに出力させる
  9. 「言葉」の衝突を解決する：同じ「ユーザー」でも場面によって意味が違う
  10. イベントストーミングを1人で：付箋の代わりにAIを使って流れを可視化する
  11. 仕様変更に強い境界線：1つの変更が1つのコンテキストで閉じるようにする
  12. AIに「このコンテキストの役割」を覚え込ませるプロンプト術
  13. 戦略的設計をサボるとどうなるか：巨大な1つの塊（ビッグボールオブマッド）の誕生
  14. プロトタイプから本番へ：境界線を徐々に固めていくプロセス
  15. 【ワーク】：作りたい機能の「単語帳」をAIと一緒に作り、不整合を直す

第4部：【設計の基礎力：戦術】AIを暴走させない「型」の作り方 (36-55)​

C#の実装スキルを、DDDのパーツ作りに応用します。

  1. 値オブジェクト (Value Object)：string や int を信じない
  2. C# record を使った最強の値オブジェクト実装法
  3. 「不変（Immutable）」の魔法：一度作った値を誰にも変えさせない安心感
  4. バリデーションの置き場所：不正な値を持つオブジェクトは、この世に誕生させない
  5. エンティティ (Entity)：名前が変わっても「同一人物」と認識する仕組み
  6. 識別子の設計：GUID、連番、それとも専用の型（UserId型）か？
  7. ドメインサービス：オブジェクトに持たせると不自然な計算の置き場所
  8. 集約 (Aggregate) 入門：関連するオブジェクトを1つの「チーム」としてまとめる
  9. 集約ルート：チームへの命令は、必ずキャプテン（ルート）を通す
  10. 1人開発での集約サイズ：AIが一度に理解できる「適切な大きさ」とは
  11. リポジトリ (Repository)：データの保存・復元を「魔法の箱」に隠す
  12. リポジトリはDBの事を知らない：SQLをドメイン層に持ち込まない
  13. C# Generics を活用した共通リポジトリの罠：やりすぎに注意
  14. ファクトリ (Factory)：複雑なオブジェクトの組み立てを専用の工場に任せる
  15. ドメインイベント：何かが起きたことを、別の場所に通知する
  16. 副作用のない関数：何度実行しても同じ結果が出る、テストしやすいロジック
  17. Resultパターンの導入：例外を投げずに、エラーを「戻り値」として扱う
  18. C# の型システムでビジネスルールを表現する：if文を型で消す
  19. AIに「DDDのパーツ」を生成させるための指示テンプレート
  20. 【演習】：C#で「お金(Money)」や「メールアドレス(Email)」を値オブジェクトで作る

第5部：【アーキテクチャ】1人のスピードを最大化する構造 (56-75)​

各パーツをどう組み合わせて、1つのアプリにするかを学びます。

  1. レイヤードアーキテクチャ：古典的だが、1人開発ならこれで十分なことも
  2. オニオンアーキテクチャ：ドメインを中心に据え、外部を「付け替え可能」にする
  3. クリーンアーキテクチャの取捨選択：1人ならフォルダ構成を簡略化する
  4. プロジェクト構成のベストプラクティス：Domain, Application, Infrastructure, Web
  5. 依存性注入 (DI) の真の目的：テスト時に「本物のDB」を使わなくて済むようにする
  6. アプリケーションサービス：ユースケース（ユーザーがやりたいこと）を実現する層
  7. DTO (Data Transfer Object)：画面に出すデータと、内部のデータを分ける理由
  8. AutoMapper vs 手動マッピング：AI時代なら手動（またはAI生成）が早い？
  9. Entity Framework Core と DDDの折り合い：マッピングの苦労を最小限にする
  10. トランザクション管理：複数の集約を一度に更新する時の作法
  11. CQRS（コマンドクエリ責務分離）の超入門：読み込みはもっと自由でいい
  12. MediatR を使うべきか、使わざるべきか：1人開発でのデバッグのしやすさ
  13. 外部API連携の設計：相手が止まっていても自分のアプリを止めない方法
  14. 設定値 (appsettings.json) とドメインの距離
  15. AIを用いたアーキテクチャ図の自動生成（PlantUML / Mermaid）
  16. ユニットテストの戦略：どこを重点的にテストし、どこをAIに任せるか
  17. モック (Moq / NSubstitute) の使い方：1人でも「偽物」を作って爆速開発
  18. アーキテクチャテスト：設計ルールを破ったらビルドエラーにする
  19. 「ディレクトリ名」で語る設計：名前を見るだけで役割がわかる配置
  20. 【演習】：ASP.NET Core でクリーンアーキテクチャの最小構成を自作する

第6部：【DDD以外の選択肢と割り切り】現実的な設計者へ (76-90)​

DDDが「重すぎる」と感じた時の、1人開発者としての逃げ道。

  1. トランザクションスクリプト：手順書のように上から下に書く、最速の実装
  2. Active Record：DBのテーブルをそのまま触る、昔ながらの楽な方法
  3. 使い分けの基準：コンテキストごとに設計手法を変えてもいい
  4. YAGNI原則：「それ、たぶん使わない」を捨ててスピードを出す
  5. DRYの罠：1人なら「同じようなコード」を無理にまとめない方がいい
  6. 技術的負債を「意図的に」作る：リリース優先の判断基準
  7. AIに「あえて設計を崩した実装」を指示するテクニック
  8. リサーチ駆動設計：正解がわからない時は、まず汚く書いてみる
  9. スモールスタートの極意：最初から完璧な集約を作ろうとしない
  10. マイクロサービスは1人開発には毒か？：モジュラーモノリスの提案
  11. スクリプト言語的アプローチ：Python/PHP/JS/TSの経験をC#にどう活かすか
  12. 設計の「賞味期限」：1年後に作り直す前提で今の設計を決める
  13. 1人でのコードレビュー術：AIに「意地悪なレビュアー」を演じさせる
  14. ドキュメントはAIに書かせる：README.md を設計図から生成する
  15. 【ワーク】：複雑な機能を「DDD版」と「簡易版」でAIに書き比べさせる

第7部：【継続と成長】AI時代に生き残る設計者になる (91-100)​

技術が変わっても通用する「設計の勘」を養います。

  1. C#の進化とDDD：Primary Constructor や Required が変える実装
  2. AIツールの活用：Visual Studio / VS Code や Antigravity にドメインルールを覚えさせる
  3. 「設計の壁」を感じた時の対処法：知識不足か、それとも業務が複雑すぎるのか
  4. 他人のコードを「設計の目」で読む：OSSやAIが生成したコードの裏側を見る
  5. 1人開発者のキャリア：設計ができると、AIを部下にした「チームリーダー」になれる
  6. ポスピタリティとしての設計：未来の自分や、引き継ぐ誰かへの思いやり
  7. 学び続けるためのリソース：書籍、ブログ、そしてAIとの対話
  8. 10年後も生き残るスキル：コード書きではなく「構造を作る力」
  9. DDDは目的地ではない：最終目的は「ユーザーが喜ぶソフトを作る」こと
  10. 総括：最初の一歩：今日からできる「1つだけの小さな設計」