Day 3 - 本日のサマリー: 設計思想を「選べる」ようになる1日
概要
- 日程: Day 3
- 本日のゴール: 主要な設計アプローチ（POA/DOA/MDA/SOA/ROA/OOAD）と多層アーキテクチャ（3層/MVC/MVVM/DDD）の違いを説明し（行動）、自分の開発テーマを題材に（条件）、採用する設計・永続化方式・通信方式を根拠付きで選択してRESTful API設計書を作成できる（基準: 選択理由を各1文以上、APIエンドポイント5本以上）
- 対応する到達目標: No.5, No.6
- 本日の成果物: 設計方針メモ（採用アプローチと根拠）、テーブル設計（正規化済み）、RESTful API設計書
🧭 今日の航海図（なぜ・なにを・どこへ）
昨日までに「何を作るか」（情報モデル・機能・画面）が決まりました。今日は「どう組み立てるか」＝設計思想を学びます。設計アプローチやアーキテクチャは略語が多くて圧倒されそうですが、実は「どこを中心に据えるか」という一つの軸で整理できます。今日が終わる頃には、自分のテーマに合う設計を根拠付きで選び、明日そのまま実装できるRESTful API設計書が手元にあります。知識を「暗記する」日ではなく「選べるようになる」日です。
⏱ 今日の流れ
| 時間 | セッション | 形式 | このセッションで手に入るもの |
|---|---|---|---|
| 9:00-9:30 | 設計思想と設計アプローチ | 座学 | 6つのアプローチを貫く「中心軸」の視点 |
| 9:30-10:15 | 自分のテーマに合う設計アプローチを選ぶ | 演習 | 採用・不採用理由つきの設計方針メモ |
| 10:30-11:00 | 多層アーキテクチャ MVC・MVVM・DDD | 座学 | 層の分け方とMVC/MVVM/DDDの違い |
| 11:00-12:00 | 設計用語をIAの手法で整理する | 演習 | 5つの設計用語の自分なりの定義 |
| 13:00-13:30 | 永続化 ACIDと正規化 | 座学 | ACID・正規化・O/Rマッピングの基礎 |
| 13:30-14:15 | 正規化と情報アーキテクチャの違いを考察する | 演習 | 正規化済みテーブル設計と考察メモ |
| 14:30-15:00 | UIと機能の通信・実行方式 | 座学 | REST/JSONと実行方式の選択の観点 |
| 15:00-15:30 | RESTful APIを設計する | 実習 | RESTful API設計書（明日の実装の設計図） |
| 15:30-16:00 | 開発手法 なぜ複数あるのか | 座学＋演習 | 開発手法の使い分けとDay3の振り返り |
午前は設計の「思想」を、午後はデータ・通信という「足回り」を押さえ、最後にAPI設計書として結晶させる1日です。
🎯 今日の成果物
夕方には、たとえば「DOAを軸に3層アーキテクチャを採用。理由は情報モデルが安定しているから」という設計方針メモと、GET /expenses POST /expenses のようなエンドポイントが5本以上並び、JSONレスポンス例まで書かれたAPI設計書が手元にあります。この設計書の精度が、明日の実装スピードをそのまま決めます。
⚠️ 今日のつまずきポイント
- 「正解のアプローチ」を探して手が止まる: 設計アプローチにも用語の分類にも唯一の正解はありません。今日の評価基準は「正しい選択」ではなく「根拠を言えること」です。迷ったらAIに反対の立場でディベートしてもらい、自分の根拠を鍛えましょう。詰まるのは考えている証拠です。
- 正規化済みテーブルを情報モデルの「上位互換」と誤解する: 情報モデルはペルソナのため、正規化はコンピュータのための設計です。役割が違う2つの姿であって、どちらかが正解ではありません。この「視点の違い」こそが今日の考察演習の狙いです。
🤖 今日のAIの使いどころ
- 設計方針を自分で書いてから、「私はDOAを選びました。あなたはOOAD推進派としてディベートして」と反論役を頼む
- API設計書を書いたら「このAPI設計をRESTの原則でレビューして。URLに動詞が混ざっていない？」とチェック役を任せる
先に自分の案を作ってからAIにぶつける、が今日も鉄則です。AIの長文に押されたら「一番重要な指摘を1つだけ選んで」と絞らせましょう。