Day 3 - 本日のサマリー: 「同じ材料」をどう料理するか、設計思想を選ぶ日

• 日程: Day 3
• 本日のゴール: DOA/MDA/SOA/ROA/OOAD、MVC/MVVM/DDDの違いを比較し、開発テーマに適した設計思想を選択できるようになる
• 対応する到達目標: No.5, No.6
• 本日の成果物: 設計アプローチ比較メモ、MVC分解図、正規化考察メモ、開発手法選択メモ

🗣️ 要約

• 今日はDay2で抽出した機能・プレゼンテーションを「どう作るか」という設計思想・アーキテクチャを学ぶ
• POA・DOA・MDA・SOA・ROA・OOADの6つの設計アプローチと、MVC・MVVMなどの多層アーキテクチャ、開発手法を扱う
• ゴールは暗記ではなく、開発テーマに合う設計思想を理由つきで選べるようになること

昨日（Day2）は、情報モデルから機能とプレゼンテーションを抽出するところまで進みました。今日はその一歩先、「それをどう作るか」という設計思想・アーキテクチャを学びます。POA・DOA・MDA・SOA・ROA・OOADという6つの設計アプローチ、MVCやMVVMといった多層アーキテクチャ、そして開発手法まで、名前だけ聞くと圧倒される量の用語が登場します。しかしゴールは暗記ではなく、「自分たちの開発テーマなら、どれを選ぶか」を理由つきで言えるようになることです。今日1日かけて選んだ設計思想が、そのまま明日（Day4）の実装の指針になります。

🗣️ 要約

• 午前は設計アプローチとMVCで全体の骨組みを決め、午後は永続化・通信・開発手法で肉付けする
• 座学と演習が交互に配置され、最後にDay3まとめで設計思想の最終選択を行う

午前は「設計アプローチとMVC」で全体の骨組みを決め、午後は「永続化・通信・開発手法」で骨組みに肉付けをしていく1日です。

🗣️ 要約

• 設計アプローチ比較メモ、MVC分解図、正規化考察メモ、開発手法選択メモの4点が完成する
• MVC分解図はDay4の実装でそのまま「どこに何を書くか」の地図として使う

夕方には、次の4点がチームの手元に揃っている状態を目指します。

• 設計アプローチ比較メモ（POA/DOA視点の書き出し、5用語の考察メモ）
• MVC分解図（機能名・Model担当・View担当・Controller担当を1枚にまとめたもの）
• 正規化考察メモ（RDBの正規化とIAの整理・分類の共通点・相違点）
• 開発手法選択メモ（不確実性・チーム規模・納期を根拠にした選択と理由）

これらはすべて「明日どう実装するか」を決めるための土台です。特にMVC分解図は、Day4の実装で「どのコードをどこに書くか」の地図として、そのまま使うことになります。

🗣️ 要約

• ControllerやViewに業務ロジックを書き込んでしまいやすい（表示方法を変えても使い回せるかで判断する）
• 設計思想や開発手法に唯一の正解を求めて議論が止まりやすいが、状況に応じた使い分けが前提

• ControllerやViewに業務ロジックを書き込んでしまう：MVC分解の演習で最も起きやすいつまずきです。「その処理は、表示方法をWebからスマホアプリに変えても使い回せるか」を自分に問いかけ、使い回せないなら書く場所を間違えているサインです。多くの受講者が最初はここでつまずくので、詰まって当然だと思ってください。
• 設計思想や開発手法に「唯一の正解」を求めて議論が止まる：POA/DOAの演習や開発手法の演習で頻出のつまずきです。今日扱う用語はどれも「優劣」ではなく「状況に応じた使い分け」です。意見が割れたら、それは良い議論ができているサインだと捉え、無理に1つにまとめずハイブリッドな結論でも構いません。

🗣️ 要約

• MVCへの分解を自分たちで終えた後、AIに変なところがないか検算してもらう
• 用語が混乱したら、暗記の前に料理や建築のたとえで違いを説明してもらうと整理しやすい

• まず自分たちで「開発テーマの機能をMVCに分解してみる」→ 分解し終えたら「この分解、AIから見て変なところはある？」と検算に使う
• 用語が混乱してきたら、暗記しようとする前に「〇〇と〇〇の違いを、料理か建築のたとえで説明して」とAIに聞いてみると、今日出てきた用語がぐっと整理しやすくなります