多層アーキテクチャとMVC・MVVM・DDD

• 日程: Day 3 / セッション 04
• 時間: [10:40-11:25]
• 形式: 実習
• ゴール: MVC・MVVM・DDDの違いを図で説明でき、自チームの開発に最適なものを根拠とともに1つ選択できる
• 学習形式: ハンズオン実習（AI比較分析あり）

前セッションでは「設計アプローチ」という大きな分類を見ました。今度はそれを実装に落とすときに使う「具体的な構造パターン」です。

エンジニア界隈で最もよく耳にする「MVC」「MVVM」「DDD」。聞いたことはあっても、違いを説明できる人は意外と少ない。本セッションでは、これらの構造を図で理解し、自チームに合うものを選択します。

ベースになるのが「多層アーキテクチャ」、特に3層アーキテクチャです。これは「家を1階・2階・3階に分ける」発想で、システムを階層に分けて責務を整理する考え方です。

ほぼすべての業務システムが、何らかの形で「3層」に分かれています。

3層に分ける目的は「変更の影響を局所化する」こと。画面の色を変えたいだけなのにDBの構造を変えなければならない、という事態を防ぎます。

3層アーキテクチャの起源は1980年代後半、クライアント・サーバ型システムの普及とともに広まりました。それ以前は「2層（クライアント＋DBサーバ）」が主流で、業務ロジックがクライアント側のFat Clientに詰め込まれていました。1990年代、Webブラウザが普及すると、ロジックをサーバ側に集中させる必要が出てきて、3層化が一気に進みました。

3層アーキテクチャを「プレゼンテーション層の中で」さらに細かく分けたパターン。1979年、Smalltalkで考案。

代表例: Ruby on Rails、Django、Spring MVC、ASP.NET MVC

MVCを「双方向データバインディング」前提に改良したパターン。2005年、MicrosoftがWPF用に考案。フロントエンド開発で主流。

代表例: Vue.js、Angular、Knockout.js、WPF

MVVMの肝は「ViewとViewModelが自動で同期する（バインディング）」こと。ViewModelの値が変わるとViewが勝手に更新される。Reactは厳密にはMVVMではない（Flux/Reduxパターン）が、似た発想を持つ。

2003年、エリック・エヴァンスが提唱。複雑な業務ロジックを持つシステムに有効。MVCやMVVMが「層の分け方」だとすれば、DDDは「業務（ドメイン）の表現の仕方」を主題にする。

DDDの主要キーワード：

• ユビキタス言語: 開発者と業務担当者が同じ言葉を使う（例: 「ユーザー」ではなく「会員」など）
• エンティティ: IDで識別される業務オブジェクト（例: 注文）
• 値オブジェクト: 値そのものに意味がある（例: 金額、住所）
• 集約: 整合性を保つ単位（例: 「注文」とその「注文明細」群）
• リポジトリ: 永続化を抽象化（DBアクセスの詳細を隠す）
• 境界づけられたコンテキスト: 用語の意味が一貫する範囲

DDDは「業務が複雑」なときに真価を発揮します。CRUDだけのシンプルなシステムにDDDを持ち込むと、過剰設計になります。「ドメインが複雑か？」が判断軸です。

エリック・エヴァンスの『ドメイン駆動設計』（青本）は600ページの大著で「読破した人は少ない」ことで有名。多くの人は『実践ドメイン駆動設計』（赤本）から入ります。さらにエンジニアの増田亨さんの『現場で役立つシステム設計の原則』は日本人にとって理解しやすいDDD入門書として広く読まれています。

設計には「定番の解法」があります。1994年、Gang of Four（GoF：Gamma・Helm・Johnson・Vlissides）が23のデザインパターンを書籍化しました。

代表的なもの：

• Singleton: インスタンスを1つに制限
• Factory: オブジェクト生成を専門の関数/クラスに任せる
• Observer: 変更を購読者に通知（イベント駆動の原型）
• Strategy: 振る舞いを差し替え可能にする

パターンは「名前」が大事です。「Strategyパターンで」と言えば、チームに伝わります。料理で言う「カラメリゼ」「ジュリエンヌ」のような共通言語です。

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

• 「MVCとMVVMをReactで比較したらどうなる？」
• 「DDDのユビキタス言語の具体例を、ECサイトを題材に作って」
• 「自分のチームの開発テーマでDDDは過剰設計？ 判断して」

チームで以下を実施してください。

1. 自チームの開発テーマに対し、MVC / MVVM / DDD のどれを採用するかを議論
2. AIに「自分たちのテーマ（〜）でMVCを採用した場合の構成図と、MVVMを採用した場合の構成図を比較して」と質問
3. 採用理由を3行でメモ

• 採用するアーキテクチャ（1つ）
• 採用理由（3行）
• 簡単な構成図（Mermaidまたは手書き）

• 「リアクティブなUIが必要」→ MVVM寄り
• 「ドメインが複雑（業務ルールが多い）」→ DDD
• 「シンプルなCRUDで素早く作る」→ MVC

3層アーキテクチャを土台に、プレゼンテーション層を整理するパターンとしてMVC・MVVMがあります。一方DDDは業務ドメインの複雑さに対処する設計思想です。これらは「対立」ではなく「組み合わせ」が可能です（例: DDDの中にMVVMのフロントエンドが入る）。

次のセッションでは、今日まで出てきた「アーキテクチャ」「設計」「駆動」「アプローチ」「パターン」という似たような言葉の違いを整理します。

• MVCとMVVMの違いを図で説明できますか？
• DDDが向くプロジェクト・向かないプロジェクトを区別できますか？
• 自チームの選択と理由を3行で言えますか？

• 参考リンク: エリック・エヴァンス『ドメイン駆動設計』、増田亨『現場で役立つシステム設計の原則』、GoF『デザインパターン』
• 発展課題: 自分が使っているフレームワーク（Express、Next.js、Vue、Laravelなど）がMVC/MVVMのどちらに近いか分析