【Python】Djangoのviews.pyが肥大化する前に行うべき「ビジネスロジックの分離」

2025年10月15日

Djangoアプリケーションの開発において、views.pyはリクエストを受け取りレスポンスを返す、まさに「交通整理役」です。しかし、開発を進めるうちに、このviews.pyファイルにデータベースへのアクセス、外部APIとの連携、メール送信といった、アプリケーションの中核をなす**「ビジネスロジック」**がどんどん追加され、肥大化していくことがよくあります。

このような設計は、コードの役割分担を曖昧にし、再利用性とテストの容易性を著しく損ないます。今回は、ビューからビジネスロジックを切り離し、**「サービスレイヤー」**と呼ばれる独立したモジュールに分離することで、クリーンで保守性の高いアーキテクチャを実現する方法を解説します。

問題点：`views.py`に混在したビジネスロジック

ユーザーが商品を購入する際の処理を考えてみましょう。views.pyにすべての処理を書くと、次のようになります。

悪い例：views.pyにビュー以外のロジックが混在

# payment/views.py
from django.shortcuts import get_object_or_404, redirect
from django.core.mail import send_mail
from .models import Item, PurchaseHistory
from some_payment_gateway import process_payment # 外部決済サービス

# --- ビジネスロジックのヘルパー関数 ---
def _record_purchase(user, item):
    """購入履歴をDBに記録する"""
    return PurchaseHistory.objects.create(item=item, user=user)

def _send_purchase_notification(user, item):
    """購入完了メールを送信する"""
    send_mail(
        "ご購入ありがとうございます",
        f"{item.name}の購入が完了しました。",
        "noreply@example.com",
        [user.email],
    )

# --- 本来のビュー（リクエストとレスポンスを扱う関数） ---
def purchase_item_view(request, item_id):
    """商品購入のHTTPリクエストを処理するビュー"""
    if not request.user.is_authenticated:
        return redirect("login")
        
    item = get_object_or_404(Item, id=item_id)

    try:
        # 決済処理、DB記録、メール送信という一連のビジネスロジック
        process_payment(user=request.user, item=item)
        _record_purchase(user=request.user, item=item)
        _send_purchase_notification(user=request.user, item=item)
    except Exception as e:
        # エラーハンドリング...
        return redirect("error_page")

    return redirect("purchase_complete_page")

このコードにはいくつかの問題があります。

役割の曖昧さ: purchase_item_viewがURLに紐づく本来の「ビュー」ですが、_record_purchaseのようなヘルパー関数も同じファイルに存在するため、どれがWebのリクエストを直接処理するエントリーポイントなのかが分かりにくくなっています。
再利用性の欠如: もし、「管理画面からの手動購入」や「夜間バッチ処理による自動購入」といった、Webリクエストを伴わない別の方法で同じ購入処理を実行したくなった場合、views.pyに実装されたロジックを安全に再利用することは困難です。
テストの困難さ: 購入処理というコアロジックをテストしたいだけなのに、HttpRequestオブジェクトをモック（模擬）するところから始めなければなりません。ビジネスロジックがWeb層と密結合しているため、独立したテストが書きにくいのです。

解決策：ビジネスロジックを「サービスレイヤー」に分離する

この問題を解決するには、ビジネスロジックをviews.pyから切り離し、services.pyのような新しいファイル（サービスレイヤー）に集約します。

ステップ1: services.pyを作成し、ビジネスロジックを移動する

paymentアプリケーション内にservices.pyというファイルを作成し、購入処理の中核を担う関数を定義します。この関数は、requestオブジェクトのようなWeb層の詳細に依存せず、純粋なPythonオブジェクト（user, item）を受け取るように設計します。

payment/services.py

from django.core.mail import send_mail
from .models import Item, PurchaseHistory, User
from some_payment_gateway import process_payment

def _record_purchase(user: User, item: Item):
    """購入履歴をDBに記録する"""
    # ... (実装は同じ)

def _send_purchase_notification(user: User, item: Item):
    """購入完了メールを送信する"""
    # ... (実装は同じ)

def purchase_item(user: User, item: Item):
    """
    商品購入に関する一連のビジネスロジックを実行するサービス関数。
    """
    # 決済、DB記録、メール送信を一手に担う
    process_payment(user=user, item=item)
    _record_purchase(user=user, item=item)
    _send_purchase_notification(user=user, item=item)

ステップ2: ビューを「指揮者」としてスリム化する

ビューは、HTTPリクエストの解釈とサービス関数の呼び出し、そして最終的なHTTPレスポンスの生成という、「指揮者」の役割に徹します。

payment/views.py

from django.shortcuts import get_object_or_404, redirect
from .models import Item
from . import services # サービスレイヤーをインポート

def purchase_item_view(request, item_id):
    """商品購入のHTTPリクエストを処理するビュー"""
    if not request.user.is_authenticated:
        return redirect("login")
        
    item = get_object_or_404(Item, id=item_id)

    try:
        # ビジネスロジックの実行をサービス関数に委任
        services.purchase_item(user=request.user, item=item)
    except Exception as e:
        # エラーハンドリング...
        return redirect("error_page")

    return redirect("purchase_complete_page")

分離によるメリット

明確な関心の分離: views.pyはWeb層の責務、services.pyはビジネスロジック層の責務、と役割が明確に分かれました。
高い再利用性: services.purchase_item関数は、ビューだけでなく、管理コマンド、API、バッチ処理など、アプリケーションのどこからでも安全に呼び出すことができます。
容易なテスト: services.pyはrequestオブジェクトに依存しないため、純粋なPythonコードとして極めて簡単に単体テストが可能です。