Djangoのアーキテクチャを学ぶ理由
Djangoの機能を最大限に活かすため
DjangoはPythonの「バッテリー同梱（batteries included）」という設計理念を踏襲しています。つまりWeb開発に必要な機能があらかじめフレームワークに含まれています。Djangoのアーキテクチャやプロジェクト構成を理解することで、これらの機能を適切に利用でき効率的に開発を進めることができます。
Djangoに組み込まれているバッテリー同梱に相当する機能を紹介します。例えば、認証システム、ORM（Object-Relational Mapping）を始めとするDB操作、フォーム作成、URLの正規表現マッチング、セキュリティ対策（CSRFトークン、SQLインジェクション対策、パスワードのハッシュ化）、メール送信機能などが挙げられます。Djangoを利用することでこのような機能を簡単に実装することができます。
開発の効率性、拡張性、保守性を高めるため
Djangoのアーキテクチャはアプリケーションの保守性と拡張性を高めるように設計されています。特に、MTVパターン（MVCパターンに相当）を採用しているため、コードを機能ごとに明確に分割でき、特定の部分を変更しても他の部分に影響を与えにくい構造になっています。
さらにDjangoのプロジェクト構成は、特定のディレクトリ構造やファイル分割を前提としています。この標準構成を理解しておくことで、複数人での開発でも一貫したコードベースを維持でき、プロジェクトが複雑になった場合でも、どこに何があるかをすぐに把握できます。
このような特性を活用しメンバーごとに開発範囲を分担することで開発効率を向上させることができ、また機能拡張や運用保守の際に対象範囲を限定しやすくなります。
アーキテクチャの全体像
全体像
それではDjangoのアーキテクチャについて全体像を説明していきます。下図はアーキテクチャ全体図の引用になります。ここで図にされているWSGIアプリケーションの範囲に記載されている用語を押さえていくことがDjangoのアーキテクチャを押さえる上で重要になります。
Djangoのアーキテクチャの全体像, 現場で使える Django の教科書《基礎編》［4.2 LTS 対応版］
上記の橙四角、緑四角の用語を中心に整理したのが下記の表になります。まずwebブラウザよりDjangoへのアクセスがあった場合、webサーバを介してASGI/WSGIサーバーにリクエストが到達します。このサーバーについては後述します。そしてリクエストがURLディスパッチャに到達し（１）～（７）の流れでレスポンスが返却されます。
| 構成要素 | 概要 |
|---|---|
| URLconf （urls.py） | URLパターンと対応するビューの情報を管理するモジュールです。指定したURLにアクセスがあったとき、どのビューを呼び出すかを定義します。 |
| URLディスパッチャ | URLconfに基づいてリクエストされたURLに対する適切なビューを呼び出します。ビューからのレスポンスやエラー処理も担当します。URLconfはあくまで設定を指し、その設定に応じて実際に動作する仕組みがURLディスパッチャになります。 |
| ビュー （views.py） | モデル、フォーム、テンプレートと連携してレスポンスを生成する処理の流れを記述します。最終的にユーザーに表示するデータを決定します。 |
| モデル （models.py） | データベースのテーブル構造を定義し、アプリケーション内でデータをオブジェクトとして扱います。ビジネスロジックもここで管理されます。 |
| テンプレート | 動的に内容を変更できるHTMLファイルです。ユーザーに表示するデータやページのレイアウトを指定します。 |
| フォーム （forms.py） | ユーザーからの入力をフォームとして扱い、入力されたデータのバリデーション（正しさの確認）も行います。 |
| ミドルウェア（middlewares.py） | リクエストが処理される前やレスポンスが返される前後に実行される処理を記述します。 |
| 設定ファイル（settings.py） | Djangoプロジェクト全体の設定をまとめて管理するファイルです。例えばデータベースや静的ファイルのパスなどを定義します。 |
MTVモデル
続いてMTVモデルを解説します。これはDjangoにおける処理の基本なのでしっかり押さえましょう。MTVモデルはよくMVCモデルと比較されて説明されることが多いのでまずはMVCモデルの理解から始めましょう。
MVC（Model-View-Controller）モデルは、ソフトウェアアーキテクチャの設計パターンで、アプリケーションの構造を整理し管理しやすくするためのものです。このモデルは、特にユーザーインターフェース（UI）を持つアプリケーションに適しています。MVC（Model-View-Controller）モデルは、アプリケーションの構造を整理するための設計パターンで、3つの主要なコンポーネントで構成されています。
まず、Modelはアプリケーションのデータとビジネスロジックを管理します。モデルはデータベースとのやり取りを担当し、データの状態やビジネスルールを保持します。具体的には、データベーステーブルやデータの検証・変換ロジックが含まれ、アプリケーションのデータ処理に関する部分を担います。
次に、View（ビュー）はユーザーインターフェースの部分を担当します。ビューはモデルから取得したデータを表示し、ユーザーが実際に見ることのできる部分を生成します。例えば、HTMLページやユーザーインターフェースのレイアウト、スタイルなどが含まれ、ビューはユーザーが情報を視覚的に確認するための役割を果たします。
最後に、Controller（コントローラー）はユーザーからの入力を処理し、適切なモデルやビューに対応させる役割を持っています。コントローラーは、ユーザーがボタンをクリックするなどのアクションを受け取り、そのアクションに基づいてモデルのデータを更新したり、ビューを更新したりします。具体的には、フォームからのデータを受け取ってモデルを更新する処理や、ユーザーの要求に応じてデータをモデルから取得し、ビューに反映させることが含まれます。
MVCとMTV, 現場で使える Django の教科書《基礎編》［4.2 LTS 対応版
続いて、MVCとMTVの違いを見ていきます。MTVはMVCの基本的な考え方（リクエストをある機構が受け取り、処理に渡し最終的にレスポンス（UIや処理結果）を返却）と似ています。しかしインターネット上にはいろいろな説明があり、かえって混乱してしまうかもしれません。
そこで上図では私が一番わかりやすいと思ってる図を紹介します。この図を見てみるとMTVはMVCのVをより詳細にわけて制御しているということがわかります。MTVのTとVがMVCの何と対応するのだろうと難しく考えず、この図を見ながらMTVにおけるそれぞれの役割を理解するといいでしょう。
WSGI/ASGIサーバー
最後にWSGI/ASGIサーバーについて解説します。読み方はウィスギー、アスギーと呼んでいます。開発時のサーバーはrunserverで実行する開発サーバーでも構いませんが、本番環境では専用の実行サーバーに変更することが望ましいです。開発用サーバーと本番用サーバーについて比較表を下記に示します。
| 特徴 | 開発用サーバー（runserver） | 本番用サーバー（ASGI/WSGIサーバー） |
|---|---|---|
| パフォーマンス | 高いパフォーマンスやスケーラビリティの最適化がされていない。 | 高いパフォーマンスとスケーラビリティを提供し、大規模トラフィックに対応。 |
| セキュリティ | セキュリティ対策が不十分で、本番環境での使用には不向き。 | セキュリティのベストプラクティスに基づいて設計されており、本番環境での運用に適している。 |
| 安定性と 耐障害性 | 安定性や耐障害性に関する機能が不足している。 | 長期間の安定した稼働を想定し、リカバリ機能や監視ツールとの統合がサポートされている。 |
| ログ管理と モニタリング | ログ管理やモニタリング機能が限られている。 | 詳細なログ管理やモニタリング機能が提供され、パフォーマンス監視やトラブルシューティングが可能。 |
| リバース プロキシとの統合 | リバースプロキシやロードバランサーとの統合に対応していない。 | NginxやApacheなどのリバースプロキシとの統合に対応し、パフォーマンスの向上やセキュリティの強化が可能。 |
続いて、本題であるWSGIサーバーとASGIサーバーの違いについて見ていきましょう。それぞれの特徴を下記に示しますが、2つサーバーの大きな特徴は同期的か非同期的かの違いがあります。ちなみにrunserverは同期的処理ですが、そのままでも構わない場合はGunicornを、非同期処理が必要な場合はUvicornを選択しましょう。
| 特徴 | WSGI (Web Server Gateway Interface) | ASGI (Asynchronous Server Gateway Interface) |
|---|---|---|
| 処理の種類 | 同期的（Synchronous） | 非同期的（Asynchronous） |
| リクエスト処理 | 同時に1つのリクエストのみ処理。処理中は他のリクエストが待機。 | 複数のリクエストを同時に処理可能。I/O待ちなどの間も処理が継続。 |
| サーバーとの通信 | Pythonアプリケーションとウェブサーバーとの標準的なインターフェース。 | 非同期処理をサポートし、WebSocketなども扱えるインターフェース。 |
| 使用例 | Django（同期的リクエスト処理）、Flaskなどの従来のウェブアプリケーション。 | Django（非同期リクエスト処理）、リアルタイム機能を持つアプリケーション。 |
| サーバー例 | Gunicornなど | Uvicornなど |
まとめ
本記事ではDjangoのアーキテクチャについて解説しました。Djangoにはどのような機能が備わっていて、どのような流れで処理が行われるかを理解しておくと開発がよりスムーズにできます。Djangoの流れは他のMVCアーキテクチャを採用したフレームワークでも活かせますので是非この記事で基本を理解しましょう！
