DRF × Vue.js 実践講座【第四講】DRFの全体構造とDjangoモデルによるデータ設計

Lecture 04: DRF Architecture & Django Model Design

← DRF × Vue.js 実践講座：まとめページに戻る | ← 第三講：プロジェクト初期セットアップとパッケージ導入

はじめに：いよいよ「第二部：バックエンド開発編」がスタート！

第三講では、フロントエンド（Vue 3 + Vite + TypeScript）の環境構築やパッケージ導入、そしてPython仮想環境（venv）の構築とDjangoプロジェクト・アプリの骨格作成を行いました。

今回から、講座は 「第二部：バックエンド開発編（Django REST Framework）」 へと突入します！

これから実際にバックエンドを構築していきますが、「いきなり何となくコードを書き始める」のは挫折の元です。
DRF（Django REST Framework）は非常に強力な反面、「シリアライザは何のためにあるのか」「リクエストはどんな順序で処理されてJSONになるのか」という全体のメンタルモデル（地図）が頭に入っていないと、コードの意図を見失ってしまいます。

そこで本講では、

1. DRF の全体構造とリクエスト処理シーケンス（時系列の流れ） を図解で徹底整理
2. データ設計の前提となる オブジェクト指向（クラス・継承・インスタンス） の基本を整理
3. 実際にコードを書いて Django モデル（ORM）の定義とデータ設計アーキテクチャ（フィールド・オプション・クラスメタ） を完全網羅

という3段階で、APIの全体像の把握からデータベースの基礎設計・モデル実装までを一気に進めていきます！

1. REST API の基本動作（REST API IN ACTION）

まずは、すべての土台となる 「REST API の基本動作」 を確認しましょう。

■ クライアントとサーバーのやりとり

• REST clients（クライアント）: PCブラウザ（Vue.js / Axios）やスマホアプリなど、APIを呼び出す側。
• REST server（サーバー）: データを管理し、要求に応じて処理を行う側（Django / DRF）。

■ HTTPメソッド（動詞）による操作

クライアントは、目的のリソース（URL）に対して HTTPメソッド を指定してリクエストを送ります。

サーバーはHTMLではなく、純粋なデータ形式である JSON を返します。これにより、クライアントがブラウザ（Vue）でもスマホアプリでも、同じAPIをそのまま共通利用できます。

2. Django と DRF の関係性（なぜ Django に DRF を乗せるのか）

続いて、私たちが開発している 「DRF プロジェクト」 の位置づけです。
「Django」と「DRF」は別個のフレームワークではなく、下図のように協力関係にあります。

「堅牢なWeb基盤である Django」の上に、「REST API に特化した便利機能を詰め込んだ DRF」を拡張として乗せている のがポイントです。

• Django の役割（土台）:
  • ORM（データベース操作・マイグレーション）: SQLを書かずにPythonクラスでDBを定義・操作。
  • セキュリティ基盤: SQLインジェクションやCSRFなどの脅威からアプリを防御。
  • 設定管理: settings.py や urls.py による全体統括。
• DRF の役割（API特化機能）:
  • シリアライザ（Serializer）: JSON と Python オブジェクトの相互変換・入力バリデーション。
  • ビューセット（ViewSet）: CRUD API を最小限のコードで一括実装。
  • 認証・権限（Token / Permissions）: JWTやトークンを用いたAPI認証とアクセス制御。
  • ブラウサブルAPI: ブラウザから直接APIをテストできるGUI。

面倒なDB接続やセキュリティはDjangoに任せ、API特有の処理（シリアライズやルーティング）はDRFの武器を使ってスマートに解決します。

3. DRF の全体像（アーキテクチャ）

では、Django / DRF の内部はどのような構造になっているのでしょうか。全体のアーキテクチャを見てみましょう。

従来の Django と DRF の最大の違いは、ビュー（View）の右側の構造です。

【従来の Django (MTV)】
ビュー ⇄ フォーム（検証） ➔ モデル ⇄ DB ➔ テンプレート（HTML組み立て） ➔ HTML返却

【DRF（本講座）】
DRF用ビュー ⇄ シリアライザ（検証・JSON変換） ⇄ モデル ⇄ DB ➔ JSON返却

• 従来の Django: フォームで入力検証し、DBのデータをテンプレート（HTML）に埋め込んでブラウザに返します。
• DRF: テンプレートやフォームは使わず、シリアライザ（Serializer） が「入力値の検証」と「JSON形式への組み立て」を一手に引き受けます。

4. 1リクエストの処理シーケンス（時系列で追うデータの流れ）

静的な構造（配置）を押さえたところで、「実際にブラウザからデータが送られた時、内部で各パーツがどんな順番で呼び出されるのか」 を時系列（シーケンス）で追ってみましょう！

下図は、ブラウザから POST /api/locations/（新規作成リクエスト）が送られた場合の完全な処理シーケンスです。

上図の通り、リクエストは 6つのステップ を順番に通過してレスポンスへと変換されます。今後のコーディングで実際に書くコードと直結する超重要フローです。

1) 入口の検問（Middleware）

• ブラウザ ➔ ミドルウェア: POST /api/locations/（Cookie や X-CSRFToken などを含む）が届きます。
• ミドルウェアでの検証:
  • CORS 検証: Vue.js（フロント）からのオリジン間通信を許可するかチェック。
  • Session / CSRF / 認証検証: 送られてきたトークンやヘッダーを検証し、リクエストの正当性を確認。不正な通信はこの時点で弾かれます。

2) ルーティング（URLconf）

• ミドルウェア ➔ URLconf (urls.py): 検問を通過したリクエストの URL（/api/locations/）を照合。
• URLconf ➔ ViewSet:
  • URL と HTTP メソッド（POST）から、呼び出すべきビューのメソッド（例: LocationViewSet.create()）を決定し、処理をディスパッチ（転送）します。

3) 入力の検証：JSON ➔ Python（Serializer: Input）

ここからが DRF の中核処理です。

• ViewSet ➔ Serializer: クライアントから届いた生データ（data=request.data）をシリアライザに渡します。
• シリアライザ内部でのバリデーション:
  • is_valid() および validate() が実行されます。
  • 型チェックや必須チェック、カスタムルール検証を行い、生の JSON データを安全な Python の型付きデータ に変換します。

4) 保存：Python ➔ SQL（ORM）

• ViewSet ➔ ORM: バリデーションを通過したら、serializer.save() を呼び出します。
• ORM ➔ SQL Server（データベース）:
  • Django ORM が自動的に INSERT または UPDATE の SQL クエリを発行。
  • データベースにレコードが書き込まれ、完了通知（OK）が戻ります。

5) 出力：Python ➔ JSON（Serializer: Output）

• ViewSet ➔ Serializer: 保存されたモデルインスタンス（Pythonオブジェクト）を再びシリアライザに渡します（instance -> serializer.data）。
• シリアライザ ➔ ViewSet:
  • Python のモデルオブジェクトを、クライアント（Vue）が受け取れる JSON 形式の辞書データ（JSON dict） に組み立て直します。

6) 応答（Response）

• ViewSet ➔ ブラウザ:
  • シリアライザが組み立てた JSON データとともに、適切な HTTP ステータスコード（新規作成時は 201 Created、取得時は 200 OK）を返却します。
• ブラウザ側の Vue 3（Axios）がこの JSON を受け取り、画面上に新しいデータが即座に反映されます！

5. settings.py へのアプリ登録（モデル作成の準備）

モデル（データベースのテーブル）を定義する前に、まずは Django プロジェクト（project/settings.py）に、私たちが作成したアプリ message と、インストールした rest_framework を認識させる必要があります。

backend/project/settings.py を開き、INSTALLED_APPS のリストに以下のように追記します。

INSTALLED_APPS = [
    # Django 標準アプリ
    'django.contrib.admin',
    'django.contrib.auth',
    'django.contrib.contenttypes',
    'django.contrib.sessions',
    'django.contrib.messages',
    'django.contrib.staticfiles',

    # サードパーティ製パッケージ
    'rest_framework',       # DRF を有効化

    # 作成した自作アプリ
    'message',              # メッセージアプリを登録
]

ここに登録しておくことで、Django は「message アプリのフォルダ内にある models.py を読み込んでテーブルを作ればいいんだな」と認識できるようになります。

6. Django モデルの基本概念と書き方

■ そもそも「オブジェクト指向」とは？（Djangoモデルを理解するための前提知識）

Django のモデル（Model）を触る前に、必ず押さえておきたいのが 「オブジェクト指向（Object-Oriented Programming: OOP）」 の考え方です。
「なぜクラスを書くのか？」「なぜ (models.Model) とカッコをつけて継承するのか？」という疑問は、オブジェクト指向の基本を押さえることですべて綺麗に繋がります。

オブジェクト指向とは、「現実世界のモノや概念をプログラム内の『オブジェクト（モノ）』として捉え、データ（属性）と振る舞い（メソッド）をひとまとめにして扱う考え方」 です。

下図のように、たとえば「車」というオブジェクトで考えてみましょう。

• 属性（プロパティ）: 色（青）、車種（SUV）、速度、燃料など、そのモノの「状態を表すデータ」
• メソッド: 走る()、止まる()、曲がる()、給油する()など、そのモノができる「振る舞い（動作）」

データと動作をバラバラに管理するのではなく、ひとつの「部品」としてまとめることで、プログラムの見通しが良くなり、再利用やメンテナンスが格段にしやすくなる のがオブジェクト指向の大きなメリットです。

■ 「クラス」「継承」「インスタンス」の3ステップ

では、プログラム上ではこのオブジェクトをどう組み立てていくのでしょうか。
基本は以下の 3つのステップ で捉えます。

1. ① クラス（設計図）:
   • まだ実体のない「型・設計図」です。社員を表す Employee という枠組みを作り、保持するデータ（氏名・部署・社員番号）や処理（自己紹介など）を定義します。
2. ② 継承（機能の引き継ぎ）:
   • すでにあるクラス（親）の内容をすべて引き継ぎ、新しい機能だけをプラスして別のクラス（子）を作る仕組み です。
   • たとえば管理職 Manager クラスを作るとき、ゼロから作り直すのではなく Employee を「継承」すれば、社員としてのデータや処理をそのまま受け継いだ上で、新しく「承認する（approve()）」というメソッドだけを追加できます。
3. ③ インスタンス（実体化）:
   • 設計図（クラス）をもとに、メモリ上に作られた具体的なデータ（実体） です。
   • 同じ Manager という設計図から、山田さん（manager1）や佐藤さん（manager2）といった個別の実体を何人でも生み出すことができます。

■ コードで見るオブジェクト指向

この「クラス ➔ 継承 ➔ インスタンス」を Python のコードに落とし込むと、次のようになります。

# ① クラス（設計図）：一般社員を定義
class Employee:
    def __init__(self, name, department, employee_id):
        self.name = name                      # 属性（プロパティ）
        self.department = department          # 属性（プロパティ）
        self.employee_id = employee_id        # 属性（プロパティ）

    def introduce(self):                      # メソッド（振る舞い）
        return f"{self.department}の{self.name}（社員番号: {self.employee_id}）です。"

# ② 継承：Employee を引き継ぎ、Manager クラスを作成
class Manager(Employee):
    def approve(self):                        # Manager 独自のメソッドを追加
        return f"{self.name}が申請を承認しました。"

# ③ インスタンス化：設計図から具体的な「実体」を2名作成
manager1 = Manager("山田 太郎", "システム課", "E001")
manager2 = Manager("佐藤 花子", "開発課", "E002")

print(manager1.introduce())  # 親(Employee)から引き継いだメソッドが呼べる
print(manager1.approve())    # 子(Manager)で追加したメソッドが呼べる

■ これが Django モデル（ORM）とどう繋がるのか？

この Python のオブジェクト指向の仕組みが、そのまま Django のデータベース設計 に直結しています。

「なぜ Django では class Message(models.Model): と書くのか？」
その理由は、Django があらかじめ用意してくれている基底クラス models.Model を「継承」するため です。

models.Model を継承するだけで、自分で面倒な SQL を書かなくても、DBへの保存（.save()）や検索（objects.all()）といった強力な ORM メソッドが最初から手に入ります。

■ モデルの基本的な書き方（構文）

それでは、backend/message/models.py を開いてみましょう。初期状態では空の from django.db import models だけが書かれています。

ここに、メッセージを管理する Message モデルを以下のように定義します。

from django.db import models

class Message(models.Model):
    """
    メッセージを管理するテーブル
    """
    title = models.CharField(max_length=100, verbose_name="タイトル")
    content = models.TextField(verbose_name="本文")
    is_read = models.BooleanField(default=False, verbose_name="既読フラグ")
    created_at = models.DateTimeField(auto_now_add=True, verbose_name="作成日時")
    updated_at = models.DateTimeField(auto_now=True, verbose_name="更新日時")

    def __str__(self):
        return self.title

■ コードの重要ポイント解説

1. models.Model を継承する（★継承の力）:
   • class Message(models.Model): と書くことで、Django が提供する基底クラス models.Model の全機能を継承しています。
   • これにより、自分でDB保存やSQL発行の処理を1行も書かなくても、.save()（保存）や .delete()（削除）、Message.objects.all()（一覧取得）といった超強力な ORM メソッドが最初から自由に使えるようになります。
2. 主キー（id）は自動生成される:
   • コード上には id を書いていませんが、Django が自動的に主キー（プライマリキー）として id = models.BigAutoField(primary_key=True) を裏側で追加してくれます。
3. __str__(self) メソッドを定義する（★振る舞いの定義）:
   • Python の特殊メソッドで、そのインスタンス（オブジェクト）を文字列として表現したときの値を返します。
   • これを書いておくと、Django の管理画面やターミナルでデータを参照したときに <Message: Message object (1)> ではなく、メッセージの title（例: "こんにちは"）が表示されるようになり、開発効率が劇的に上がります。

7. フィールドクラス（Field Classes）一覧と特徴

モデルの各カラムを定義する際に使うのが、Django が提供する フィールドクラス（Field クラス） です。
フィールドクラスを指定することで、「そのカラムがどんな型のデータを保持するのか」「どんな制約をかけるのか」を決定します。

代表的なフィールドクラスと、データベース上のカラム型、役割は以下の通りです。

8. フィールドオプション（Field Options）一覧

各フィールドクラスのカッコ () の中に指定する引数が フィールドオプション です。
データベースのカラム制約（NOT NULL や UNIQUE など）や、DRF のシリアライザで機能するバリデーションルールを細かくコントロールできます。

実務で必ず押さえておくべき主要オプションは以下の通りです。

9. クラスメタ（Meta クラス）によるモデル設定

モデルクラスの内部に class Meta: を定義することで、テーブル全体に関わる動作やメタ情報をカスタマイズできます。

class Message(models.Model):
    title = models.CharField(max_length=100)
    created_at = models.DateTimeField(auto_now_add=True)

    class Meta:
        db_table = 'custom_message'      # テーブル名を明示的に指定
        ordering = ['-created_at']       # 新しい順（降順）で取得
        verbose_name = 'メッセージ'
        verbose_name_plural = 'メッセージ'  # 複数形も統一

class Meta で設定できる主要な項目一覧です。

実務では、特に ordering（並び順） と verbose_name_plural（管理画面の日本語化） はほぼすべてのモデルで設定します。

10. （参考）モデルのフック（ライフサイクルメソッド）

Django のモデルには、データが「保存される瞬間」や「削除される瞬間」など、モデルのライフサイクルに合わせて自動で呼び出される フック（メソッド） が用意されています。

序盤のうちは、先ほどコード解説で登場した __str__()（表示用の文字列を返す） をしっかり押さえておけば開発に困ることはありません。発展的なカスタマイズとして、以下のようなメソッドが存在することを頭の片隅に置いておくと良いでしょう。

まとめ

第四講では、DRF の全体アーキテクチャの把握から、Django ORM による本格的なデータ設計（モデル）の基礎までを一気に学びました！

• REST API & DRF の全体像:
  • クライアントとサーバー間の JSON 通信と HTTP メソッド（GET/POST/PUT/DELETE）。
  • Django の強固な基盤の上に、DRF の武器（Serializer / ViewSet）が乗る構造。
• 1リクエストの処理シーケンス:
  • ミドルウェアによる検問 ➔ URLルーティング ➔ ViewSet ➔ Serializer入力検証 ➔ ORM経由のDB保存 ➔ Serializer出力整形 ➔ レスポンス返却という 6 ステップの流れ。
• オブジェクト指向と Django モデル（ORM）の関係:
  • クラス（設計図）➔ テーブル、属性（データ）➔ カラム、インスタンス（実体）➔ レコードという美しい対応関係。
  • models.Model を継承することで、SQLを書かずに強力なORM機能を自在に扱える。
• モデルの書き方とフィールドクラス:
  • models.Model 継承によるテーブル定義と、CharField や DateTimeField など多彩なフィールド型。
• フィールドオプション & クラスメタ:
  • null/blank や on_delete などのオプション制約。
  • class Meta による並び順（ordering）やテーブル名の一括管理。
  • __str__() を定義して管理画面での視認性を大幅アップ。

次回予告

次回は 【第五講】マイグレーション完全攻略・Django管理画面とリレーション設計 に進みます！

今回定義した Python のモデルを、いよいよコマンド（makemigrations / migrate）を使って実際のデータベース（SQLite）へと安全に反映させます。
さらに、Django 組み込みの超強力な「管理画面（Admin）」を有効化し、ブラウザからデータをポチポチ追加・確認できる環境を整えていきましょう。お楽しみに！

← 第三講：プロジェクト初期セットアップとパッケージ導入 | まとめページに戻る | 第五講へ →