多層アーキテクチャ（3層アーキテクチャ・MVC・MVVM・DDD）

• 日程: Day 3 / セッション5
• 時間: [11:30-12:00]
• 形式: 座学
• ゴール: 3層アーキテクチャ（データ層・ロジック層・プレゼンテーション層）とMVC、MVVMの対応関係を説明できる
• 学習形式: 対話型解説

🗣️ 要約

• レストランのホール・厨房スタッフ・キッチンのように、ソフトウェアにも混ざり合わない役割分担がある
• 3層アーキテクチャ・MVC・MVVMはそれぞれの役割分担を表す考え方
• Day2で作った機能一覧・プレゼンテーション一覧は、これらの層のどこかに対応する

前のセッションでは、「アーキテクチャ」「設計」「駆動」「アプローチ」「パターン」という5つの言葉の違いを、IAの手法を使って整理しましたね。今回はその中の「パターン」を、実際のソフトウェアの「層」という切り口で見ていきます。

ところで、レストランを思い浮かべてください。お客様と接する「ホール」、注文を厨房に伝え料理を運ぶ「厨房スタッフ」、実際に調理する「キッチン」。この3つの役割は、混ざり合っていません。ホールがキッチンで炒め物をすることはありませんよね。

実は、ソフトウェアにも同じような役割分担があります。このセッションが終わる頃には、「3層アーキテクチャ」「MVC」「MVVM」という言葉を聞いて、それぞれがどの役割を担っているか説明できるようになっています。そして、Day2で自分たちが作った「機能一覧」「プレゼンテーション一覧」が、実はこの層のどこに当てはまるのかも見えてきます。

🗣️ 要約

• 3層アーキテクチャはプレゼンテーション層・ロジック層・データ層に分ける考え方
• MVC・MVVMは3層アーキテクチャを具体的なプログラム構造として表したパターン
• DDDはMVCのModelをより厳密に設計するための思想

🗣️ 要約

• プレゼンテーション層は画面・入出力、ロジック層は計算・判定・業務ルール、データ層は保存・取得を担う
• 層を分けることで、画面だけ・保存方法だけを変更しても他の層に影響しにくくなる
• 「層を分ける」とは役割（責任）が分かれていることであり、単にファイルを分けることではない

まず具体例から入ります。皆さんが使っている家計簿アプリを想像してください。

• 画面に金額を入力してボタンを押す部分 → これは「見た目」の担当です
• 「支出を合計する」「予算オーバーを判定する」という計算をする部分 → これは「業務ロジック」の担当です
• 入力した金額を保存しておく部分 → これは「データの保管」の担当です

この3つを分けて考えるのが、3層アーキテクチャです。

• プレゼンテーション層：ユーザーが直接触れる画面・入出力の部分
• ロジック層（ビジネスロジック層）：計算・判定・業務ルールを処理する部分
• データ層：情報を保存・取得する部分（データベースやファイル）

なぜ分けるのでしょうか？ここで少し考えてみてください。もし画面のコードとデータ保存のコードが1つのプログラムにぐちゃぐちゃに混ざっていたら、画面のデザインを1つ変えるだけで、データ保存の処理まで壊れてしまうかもしれません。層を分けることで、「画面だけ直したい」「保存方法だけ変えたい」という変更が、他の層に影響しにくくなります。これはDay2で学んだ「情報の設計とシステムの設計を分離する」という考え方の、実装レベルでの具体化だと言えます。

ここで、Day2の演習を思い出してみましょう。皆さんが抽出した「プレゼンテーション一覧」はプレゼンテーション層に、「機能一覧」の多くはロジック層とデータ層にまたがって実装されることになります。

3層アーキテクチャを図にすると、次のような関係になります。

特に注意してほしいのは、「層を分ける」ことと「ファイルを分ける」ことは必ずしもイコールではない、という点です。よくある間違いとして、ファイルさえ分ければ層が分離できていると思い込むケースがありますが、正しくは「役割（責任）」が分かれているかどうかが本質です。画面のファイルの中に業務計算のロジックがベタ書きされていたら、ファイルが分かれていても層は分離できていません。

3層アーキテクチャという考え方が広まる前、初期のコンピュータシステムでは、画面・ロジック・データがすべて1つのプログラムに詰め込まれていました。これを「スパゲッティコード」と呼びます。まさに、麺が絡み合ってどこからどこまでか分からなくなる様子にたとえた言葉です。ある改修作業で、たった1行の画面表示を直しただけで、まったく関係ないはずの在庫管理の処理が壊れてしまった、という笑えない実話も伝えられています。層を分けるという発想は、こうした「絡み合いすぎた麺」を解きほぐす知恵から生まれたのです。

🗣️ 要約

• MVCはModel（データとロジック）・View（画面表示）・Controller（操作の取り次ぎ）から成る
• MVVMはControllerの代わりにViewModelを置き、ViewとModelの状態を自動的に同期する
• DDDでは業務知識を「ドメイン」と呼び、ドメインモデルを開発者とビジネス側が共通の言葉（ユビキタス言語）で表現する

3層アーキテクチャをさらに具体的なプログラムの構造として表したパターンの1つが、MVC（Model View Controller）です。

• Model：データとロジックを持つ部分（3層アーキテクチャのロジック層・データ層に近い）
• View：画面表示を担当する部分（プレゼンテーション層に近い）
• Controller：ユーザーの操作を受け取り、ModelとViewをつなぐ部分

たとえるなら、レストランのControllerは「注文を受けるホールスタッフ」、Modelは「調理と食材管理をするキッチン」、Viewは「盛り付けられて出てくる料理そのもの」です。ホールスタッフ（Controller）はお客様の注文（操作）を受け取り、キッチン（Model）に伝え、できあがった料理（View）をお客様に届けます。

MVVMはMVCの発展形で、Controllerの代わりにViewModelという役割を置きます。ViewModelはViewの状態を管理し、Viewと自動的に同期する点がControllerと異なります。たとえば、Modelの数値が変わったら、ViewModelを介して画面が自動的に更新される、というような仕組みです。近年のフロントエンドフレームワークの多くがMVVMに近い考え方を採用しています。

ここまでで、MVCの3つの役割それぞれが3層アーキテクチャのどの層に近いか、イメージできましたか？もし曖昧なら、AIに「MVCと3層アーキテクチャの対応関係を表にして」と聞いてみるのもよいでしょう。

最後に、ドメイン駆動設計（DDD）にも触れておきます。DDDでは、業務知識そのものを「ドメイン」と呼び、ドメインに関する処理をまとめた部分を「ドメイン層」と呼びます。Modelの中でも特に業務ルールの核心部分を指す「ドメインモデル」を、開発者とビジネス側が同じ言葉（ユビキタス言語）で表現しよう、という考え方です。DDDは、MVCのModelをより厳密に設計するための思想だと捉えると理解しやすくなります。

🗣️ 要約

• MVCとMVVMの違い、DDDのユビキタス言語と変数名の違い、自分たちの開発テーマでのModelの内容などをAIに質問できる

ここまでの内容で疑問があれば、AIに質問してみましょう。たとえば：

• 「MVCとMVVMの違いをもっと具体的な例で説明して」
• 「DDDのユビキタス言語って、普通の変数名と何が違うの？」
• 「自分たちの開発テーマだと、Modelには何が入る？」

🗣️ 要約

• 見た目・ロジック・データを役割ごとに分けて考えることが本質
• 3層アーキテクチャという大枠を、MVC・MVVMが実装レベルで具体化し、DDDが業務ルールを厳密に扱う
• 次回は開発テーマを実際にMVCで分解する演習を行う

今回学んだことを一言でまとめると、「見た目・ロジック・データを役割ごとに分けて考える」ということです。3層アーキテクチャという大枠と、それを実装レベルで具体化したMVC・MVVM、さらに業務ルールを厳密に扱うDDDという流れで理解できましたね。

次回は、開発テーマを実際にMVCで分解する演習を行います。今回の3つの役割分担の知識が土台になるので、レストランの例（ホール・厨房スタッフ・キッチン）を思い出しながら臨みましょう。

🗣️ 要約

• プレゼンテーション層・ロジック層・データ層を具体例つきで説明できるか
• MVCのController・Model・Viewが3層アーキテクチャのどこに対応するか説明できるか

以下の問いに答えられるか確認してみましょう：

• プレゼンテーション層・ロジック層・データ層を、それぞれ具体例つきで説明できますか？
• MVCのController、Model、Viewが3層アーキテクチャのどこに対応するか説明できますか？

答えに自信がない場合は、該当部分を読み返すか、AIに質問してみてください。

🗣️ 要約

• 参考資料は各自が使うフレームワーク（React・Vue・Angular等）公式ドキュメントの「アーキテクチャ概要」
• 発展課題は、普段使うスマホアプリを1つ選び3層アーキテクチャで分解すること

• 参考リンク: 各自の開発環境で使うフレームワーク（React、Vue、Angular等）の公式ドキュメントにある「アーキテクチャ概要」のページ
• 発展課題: 自分たちが普段使っているスマホアプリを1つ選び、3層アーキテクチャで分解してみる

🗣️ 要約

• 受講者からよく出る質問への回答例と、つまずきやすいポイントへの対処法をまとめている

このセクションは、受講者が理解を深めることをサポートする参考情報です。

🗣️ 要約

• MVCとMVVMはフレームワークの設計思想によって決まる（React・Vue系はMVVMに近く、伝統的サーバサイドMVCはMVCに近い）
• DDDは必須ではなく、業務ルールが複雑になるほど効果を発揮する

🗣️ 要約

• Controllerに業務ロジックを書きすぎてしまいやすいが、判断や計算はModelの役目
• 3層アーキテクチャとMVCを同じものと混同しやすいが、抽象度が異なる（概念上の分け方 vs 実装パターン）