Django برای پروژه‌های پایتونی؛ چرا بدون درک این اصول پروژه‌ات زمین می‌خورد؟

Django برای پروژه‌های پایتونی، یکی از پرتکرارترین انتخاب‌های تیم‌های بک‌اند است؛ از استارتاپ‌های کوچک تا پلتفرم‌های بزرگ داده‌محور. اما آنچه Django ارائه می‌دهد، یک فریم‌ورک آماده با فلسفه «Batteries Included» است که اگر با درک عمیق معماری، ORM (Object-Relational Mapping) و لایه‌های امنیتی همراه نشود، در مقیاس به یک بدهی فنی سنگین تبدیل می‌شود. نوشتار پیش‌رو، دقیقاً همین مرز باریک بین «ساخت سریع» و «پروژه‌ای که در مقیاس فرو می‌ریزد» را بررسی می‌کند.

در بازبینی ده‌ها پروژه Django در سال‌های گذشته، یک الگوی آشنا دیده‌ام: تیم‌ها در سه ماه اول با سرعت بالا پیش می‌روند، اما از ماه ششم هر قابلیت جدید چند برابر زمان می‌برد. دلیل این تغییر، در خود فریم‌ورک نیست؛ در نحوه استفاده از آن است. Django ابزارهایی ارائه می‌دهد که اگر درست به‌کار روند، سال‌ها موتور سرعت پروژه می‌مانند.

چرا Django انتخاب اول پروژه‌های پایتونی است؟

Django یک فریم‌ورک وب مبتنی بر پایتون است که بر اساس Django در ویکی‌پدیا برای ساخت اپلیکیشن‌های وب مقیاس‌پذیر طراحی شده است. فلسفه اصلی آن، «Batteries Included» است؛ یعنی بخش بزرگی از نیازهای رایج (احراز هویت، مدیریت محتوا، مدیریت دیتابیس، فرم‌ها) از پیش در فریم‌ورک وجود دارد. اگر با مبانی فریم‌ورک‌های بک‌اند آشنا نیستید، تفاوت فریم‌ورک‌های بک‌اند نقطه شروع مناسبی است.

پنج لایه‌ای که Django را به انتخاب اول تبدیل می‌کند:

لایه اول، ORM قدرتمند. Django ORM کار با دیتابیس را از SQL خالص به یک لایه شیءگرا تبدیل می‌کند. اگر با مفهوم ORM آشنا نیستید، راهنمای ORM و ساده‌سازی کار با دیتابیس این لایه را باز می‌کند.

لایه دوم، Admin Panel داخلی. یک پنل مدیریت حرفه‌ای که بدون هیچ کد اضافه، امکان CRUD (Create, Read, Update, Delete) روی مدل‌ها را فراهم می‌کند.

لایه سوم، Migration System. نسخه‌بندی دیتابیس که تغییرات ساختار را در تیم هماهنگ می‌کند.

لایه چهارم، امنیت پیش‌فرض. Django به‌طور پیش‌فرض از XSS (Cross-Site Scripting)، CSRF (Cross-Site Request Forgery) و SQL Injection جلوگیری می‌کند. اگر با این حوزه آشنا نیستید، اصول امنیت وب چارچوب کاملی ارائه می‌دهد.

لایه پنجم، اکوسیستم بالغ. Django REST Framework، Celery، Channels و صدها پکیج دیگر که برای هر نیاز، راه‌حل آماده ارائه می‌کنند.

Django سرعت اولیه را هدیه می‌دهد، اما سرعت بلندمدت را باید خودتان بسازید؛ تفاوت این دو، تفاوت بین یک پروژه موفق و یک فاجعه فنی است.

برای درک عمیق‌تر مسیر یادگیری Django، آموزش جنگو برای مبتدیان نقطه شروع مناسبی است. اما اگر با مبانی پایتون آشنا نیستید، ابتدا آموزش پایتون از صفر را مرور کنید.

معماری MVT و مرزهای دقیق آن

Django بر پایه الگوی MVT (Model-View-Template) ساخته شده که نسخه‌ای از الگوی کلاسیک MVC (Model-View-Controller) است. در این الگو، مسئولیت‌ها به سه لایه تقسیم می‌شوند: Model (لایه داده)، View (لایه منطق) و Template (لایه نمایش).

اگر با مبانی الگوهای معماری آشنا نیستید، آموزش الگوی MVC با مثال عملی چارچوب کاملی ارائه می‌دهد. اما در Django، تفاوت‌هایی وجود دارد که باید در نظر گرفت.

project/
├── manage.py
├── config/
│   ├── settings/
│   │   ├── base.py
│   │   ├── development.py
│   │   └── production.py
│   ├── urls.py
│   └── wsgi.py
└── apps/
    ├── users/
    │   ├── models.py
    │   ├── views.py
    │   ├── serializers.py
    │   ├── services.py
    │   ├── selectors.py
    │   └── urls.py
    └── orders/
        ├── models.py
        ├── views.py
        ├── serializers.py
        ├── services.py
        └── urls.py

در پروژه‌های بزرگ، لایه‌های میانی مثل Service و Selector نقش کلیدی دارند:

Service Layer. مسئول منطق کسب‌وکار و تغییر state:

# apps/orders/services.py
from django.db import transaction
from .models import Order
from apps.users.models import User


@transaction.atomic
def create_order(user: User, items: list[dict]) -> Order:
    order = Order.objects.create(user=user)
    for item in items:
        order.items.create(
            product_id=item['product_id'],
            quantity=item['quantity'],
        )
    return order

Selector Layer. مسئول خواندن داده و کوئری‌ها:

# apps/orders/selectors.py
from .models import Order


def get_user_orders(user_id: int):
    return (
        Order.objects
        .filter(user_id=user_id)
        .select_related('user')
        .prefetch_related('items')
        .order_by('-created_at')
    )

این جداسازی، تفاوت محسوسی در نگهداشت‌پذیری ایجاد می‌کند. اگر با مبانی معماری نرم‌افزار آشنا نیستید، ساختاربندی پروژه توسعه چارچوبی از این لایه‌ها ارائه می‌دهد.

سه قاعده ساده برای ساختار سالم:

قاعده اول، Views نازک. View باید فقط درخواست را دریافت، به Service ارسال و پاسخ را بازگرداند.

قاعده دوم، Models بدون منطق پیچیده. مدل‌ها فقط ساختار داده و روابط را تعریف می‌کنند.

قاعده سوم، Services متمرکز. منطق کسب‌وکار در Serviceهایی که مستقل از HTTP قابل تست هستند.

Django ORM؛ دوست یا دشمن مقیاس؟

Django ORM یکی از قدرتمندترین ORMهای پایتون است، اما همین قدرت در پروژه‌های بزرگ به یک دام تبدیل می‌شود اگر بدون درک عمیق استفاده شود. مشکل اصلی، پدیده‌ای به نام N+1 Query است.

# الگوی N+1 (کند)
orders = Order.objects.all()

for order in orders:
    print(order.user.email)  # یک کوئری برای هر order

# راه‌حل با select_related (سریع)
orders = Order.objects.select_related('user').all()

for order in orders:
    print(order.user.email)  # بدون کوئری اضافه

تفاوت select_related و prefetch_related. یکی از مهم‌ترین تصمیم‌ها در بهینه‌سازی:

select_related. برای روابط ForeignKey و OneToOne، با استفاده از JOIN در سطح SQL:

Order.objects.select_related('user', 'payment')

prefetch_related. برای روابط ManyToMany و Reverse ForeignKey، با استفاده از کوئری جداگانه و ترکیب در پایتون:

Order.objects.prefetch_related('items', 'items__product')

متدهای بهینه‌سازی پیشرفته.

# فقط ستون‌های ضروری
User.objects.only('id', 'email')

# همه ستون‌ها به‌جز ستون‌های سنگین
User.objects.defer('bio', 'avatar')

# محاسبه aggregation در سطح دیتابیس
from django.db.models import Count, Sum

Post.objects.annotate(
    comment_count=Count('comments'),
    total_likes=Sum('likes__weight'),
)

# Subquery برای فیلترهای پیچیده
from django.db.models import OuterRef, Subquery

latest_order = Order.objects.filter(
    user=OuterRef('pk')
).order_by('-created_at').values('total')[:1]

User.objects.annotate(
    last_order_total=Subquery(latest_order)
)

مفهوم QuerySet Laziness. QuerySet در Django به‌طور Lazy ارزیابی می‌شود؛ یعنی تا زمانی که داده واقعاً نیاز نشود، کوئری اجرا نمی‌شود. درک این رفتار، از کوئری‌های اضافی جلوگیری می‌کند:

# بدون اجرای کوئری
qs = User.objects.filter(is_active=True)

# کوئری اینجا اجرا می‌شود
for user in qs:
    print(user.email)

# این کوئری جدید است
active_count = qs.count()

در سطح پروژه‌های بزرگ، یکی از ابزارهای کلیدی، django-debug-toolbar است که تعداد و زمان کوئری‌ها را نمایش می‌دهد. برای بهینه‌سازی عمیق‌تر، بهینه‌سازی کوئری‌های MySQL چارچوبی از این لایه‌ها ارائه می‌دهد.

Indexes در سطح مدل. یکی از تصمیم‌های کلیدی برای عملکرد:

class Order(models.Model):
    user = models.ForeignKey(User, on_delete=models.CASCADE)
    status = models.CharField(max_length=20, db_index=True)
    created_at = models.DateTimeField(auto_now_add=True)

    class Meta:
        indexes = [
            models.Index(fields=['user', 'status']),
            models.Index(fields=['-created_at']),
        ]

Views و URL Routing در عمق

Views و URL Routing، لایه ورودی هر درخواست در Django هستند. تسلط بر این لایه، امکان ساخت ساختارهای پاک و قابل نگهداری را فراهم می‌کند.

تفاوت Function-Based View و Class-Based View.

# Function-Based View
def order_list(request):
    orders = Order.objects.filter(user=request.user)
    return render(request, 'orders/list.html', {'orders': orders})

# Class-Based View
from django.views.generic import ListView

class OrderListView(ListView):
    model = Order
    template_name = 'orders/list.html'
    context_object_name = 'orders'

    def get_queryset(self):
        return Order.objects.filter(user=self.request.user)

Class-Based View برای ساختارهای استاندارد مناسب است، اما در سناریوهای پیچیده، Function-Based View خوانایی بیشتری دارد.

URL Routing پیشرفته.

# config/urls.py
from django.urls import path, include

urlpatterns = [
    path('admin/', admin.site.urls),
    path('api/v1/', include('apps.api.v1.urls')),
    path('api/v2/', include('apps.api.v2.urls')),
]

# apps/api/v1/urls.py
from django.urls import path
from rest_framework.routers import DefaultRouter

router = DefaultRouter()
router.register('orders', OrderViewSet)

urlpatterns = router.urls

Namespace و Named URL. یکی از قابلیت‌های مهم که از تکرار مسیرها جلوگیری می‌کند:

# apps/orders/urls.py
app_name = 'orders'

urlpatterns = [
    path('', OrderListView.as_view(), name='list'),
    path('<int:pk>/', OrderDetailView.as_view(), name='detail'),
]

# استفاده در Template
<a href="{% url 'orders:detail' order.pk %}">{{ order.title }}</a>

# استفاده در View
from django.urls import reverse
url = reverse('orders:detail', args=[order.pk])

در سطح پیشرفته، یکی از تصمیم‌های مهم، نسخه‌بندی API است. اگر با این حوزه آشنا نیستید، اصول طراحی URI در API چارچوبی از این لایه‌ها ارائه می‌دهد.

Templates و جداسازی لایه نمایش

Django Template Language (DTL)، موتور قالب‌بندی پیش‌فرض Django است که ترکیبی از سادگی و قدرت را ارائه می‌دهد. این لایه، امکان جداسازی کامل منطق از نمایش را فراهم می‌کند.

{% extends "base.html" %}

{% block content %}
    <h1>سفارش‌های من</h1>

    {% if orders %}
        <ul>
            {% for order in orders %}
                <li>
                    <a href="{% url 'orders:detail' order.pk %}">
                        {{ order.title }}
                    </a>
                    - {{ order.created_at|date:"Y/m/d" }}
                </li>
            {% endfor %}
        </ul>
    {% else %}
        <p>هیچ سفارشی یافت نشد.</p>
    {% endif %}
{% endblock %}

فیلترهای پیشرفته DTL.

{{ post.content|truncatewords:30 }}
{{ user.last_login|timesince }}
{{ price|floatformat:2 }}
{{ text|linebreaks }}
{{ items|length }}
{{ html|safe }}  {# فقط با احتیاط #}

Template Tags سفارشی. یکی از قابلیت‌های پیشرفته که امکان گسترش DTL را فراهم می‌کند:

# apps/blog/templatetags/blog_tags.py
from django import template

register = template.Library()


@register.simple_tag
def reading_time(content: str) -> str:
    word_count = len(content.split())
    minutes = max(1, word_count // 200)
    return f"{minutes} دقیقه مطالعه"

استفاده در قالب:

{% load blog_tags %}

<p>{% reading_time post.content %}</p>

Inclusion Tags. یکی از قابلیت‌های قدرتمند که امکان رندر یک قالب با داده‌های مشخص را فراهم می‌کند:

@register.inclusion_tag('blog/partials/post_card.html')
def post_card(post):
    return {'post': post}

در سطح پروژه‌های بزرگ، یکی از تصمیم‌های مهم، استفاده از select_related و prefetch_related در View است تا در Template، کوئری اضافه زده نشود.

احراز هویت و امنیت در Django

Django مجموعه‌ای از ابزارهای امنیتی داخلی ارائه می‌دهد که بخش بزرگی از نیازهای امنیتی پروژه را بدون کد اضافی برطرف می‌کنند.

سیستم احراز هویت داخلی.

from django.contrib.auth import authenticate, login, logout
from django.contrib.auth.decorators import login_required


def login_view(request):
    if request.method == 'POST':
        username = request.POST['username']
        password = request.POST['password']
        user = authenticate(request, username=username, password=password)

        if user is not None:
            login(request, user)
            return redirect('dashboard')

    return render(request, 'auth/login.html', {})


@login_required
def dashboard_view(request):
    return render(request, 'dashboard.html')

مدل User سفارشی. یکی از بهترین تصمیم‌ها در ابتدای پروژه:

# apps/users/models.py
from django.contrib.auth.models import AbstractUser
from django.db import models


class User(AbstractUser):
    email = models.EmailField(unique=True)
    phone = models.CharField(max_length=20, blank=True)

    USERNAME_FIELD = 'email'
    REQUIRED_FIELDS = ['username']

تعریف در settings:

AUTH_USER_MODEL = 'users.User'

این تصمیم، فقط در ابتدای پروژه قابل اعمال است. اگر بعداً نیاز به User سفارشی داشته باشید، مهاجرت پرهزینه‌ای در پیش خواهد بود.

دسترسی‌ها و Permission. Django سه لایه دسترسی ارائه می‌دهد:

# سطح View
from django.contrib.auth.decorators import permission_required


@permission_required('orders.add_order', raise_exception=True)
def create_order(request):
    pass


# سطح Template
{% if perms.orders.add_order %}
    <a href="{% url 'orders:create' %}">سفارش جدید</a>
{% endif %}


# سطح Model
from django.contrib.auth.mixins import PermissionRequiredMixin

class OrderCreateView(PermissionRequiredMixin, CreateView):
    permission_required = 'orders.add_order'
    model = Order

محافظت‌های داخلی Django.

# CSRF Protection (فعال به‌طور پیش‌فرض)
{% csrf_token %}

# XSS Protection (خودکار در Template)
{{ user_content }}  {# به‌طور پیش‌فرض Escape می‌شود #}

# SQL Injection Protection (خودکار در ORM)
User.objects.filter(email=email)  {# پارامتری شده #}

# Clickjacking Protection
X_FRAME_OPTIONS = 'DENY'

# Security Headers
SECURE_HSTS_SECONDS = 31536000
SECURE_SSL_REDIRECT = True
SESSION_COOKIE_SECURE = True
CSRF_COOKIE_SECURE = True

در سطح پروژه‌های API، یکی از نکات کلیدی این است که احراز هویت مبتنی بر Token به‌طور پیش‌فرض امن نیست. استفاده از JWT (JSON Web Token) با عمر محدود یا OAuth2 توصیه می‌شود. اگر با این حوزه آشنا نیستید، امنیت REST API چارچوب کاملی ارائه می‌دهد.

امنیت در Django یک ویژگی آماده نیست، یک نگرش است؛ ابزارها فقط بخشی از کار را انجام می‌دهند و بخش بزرگ‌تر، به تصمیم‌های معماری بستگی دارد.

Forms و اعتبارسنجی داده

Django Forms، یکی از قدرتمندترین ابزارهای این فریم‌ورک است که اعتبارسنجی، پاک‌سازی و رندر فرم را در یک لایه جمع می‌کند.

فرم پایه.

from django import forms


class OrderForm(forms.Form):
    product_id = forms.IntegerField(min_value=1)
    quantity = forms.IntegerField(min_value=1, max_value=100)
    notes = forms.CharField(
        widget=forms.Textarea,
        required=False,
        max_length=500,
    )

    def clean_quantity(self):
        quantity = self.cleaned_data['quantity']
        if quantity > 10:
            raise forms.ValidationError('حداکثر تعداد ۱۰ عدد است.')
        return quantity

ModelForm. فرم مبتنی بر Model که بخش بزرگی از کارها را خودکار می‌کند:

class OrderForm(forms.ModelForm):
    class Meta:
        model = Order
        fields = ['product', 'quantity', 'notes']
        widgets = {
            'notes': forms.Textarea(attrs={'rows': 4}),
        }
        labels = {
            'product': 'محصول',
            'quantity': 'تعداد',
        }

اعتبارسنجی سفارشی در سطح فرم.

class OrderForm(forms.ModelForm):
    def clean(self):
        cleaned_data = super().clean()
        product = cleaned_data.get('product')
        quantity = cleaned_data.get('quantity')

        if product and quantity and quantity > product.stock:
            self.add_error(
                'quantity',
                f'موجودی کافی نیست. حداکثر {product.stock} عدد.'
            )

        return cleaned_data

Formsets. یکی از قابلیت‌های پیشرفته که امکان مدیریت چند فرم مرتبط را فراهم می‌کند:

from django.forms import inlineformset_factory


OrderItemFormSet = inlineformset_factory(
    Order,
    OrderItem,
    fields=['product', 'quantity'],
    extra=1,
    can_delete=True,
)

این الگو، در سناریوهایی مثل سفارش با چند آیتم، فاکتور با چند ردیف، یا مقاله با چند بخش، بسیار مفید است.

Admin Panel و سفارشی‌سازی آن

Admin Panel یکی از جذاب‌ترین قابلیت‌های Django است که بدون هیچ کد اضافه، یک پنل مدیریت کامل فراهم می‌کند. اما در پروژه‌های واقعی، سفارشی‌سازی این پنل بخش مهمی از کار است.

ثبت مدل در Admin.

from django.contrib import admin
from .models import Order, OrderItem


class OrderItemInline(admin.TabularInline):
    model = OrderItem
    extra = 1


@admin.register(Order)
class OrderAdmin(admin.ModelAdmin):
    list_display = ['id', 'user', 'status', 'total', 'created_at']
    list_filter = ['status', 'created_at']
    search_fields = ['user__email', 'id']
    readonly_fields = ['created_at', 'updated_at']
    inlines = [OrderItemInline]

    fieldsets = (
        ('اطلاعات اصلی', {
            'fields': ('user', 'status', 'total')
        }),
        ('زمان‌ها', {
            'fields': ('created_at', 'updated_at'),
            'classes': ('collapse',),
        }),
    )

    def get_queryset(self, request):
        return super().get_queryset(request).select_related('user')

Actions سفارشی. یکی از قابلیت‌های پرکاربرد:

@admin.action(description='علامت‌گذاری به‌عنوان ارسال‌شده')
def mark_as_shipped(modeladmin, request, queryset):
    queryset.update(status='shipped')

@admin.register(Order)
class OrderAdmin(admin.ModelAdmin):
    actions = [mark_as_shipped]

Admin Site سفارشی. برای تغییر عنوان، رنگ و ساختار پنل:

admin.site.site_header = 'پنل مدیریت فروشگاه'
admin.site.site_title = 'فروشگاه'
admin.site.index_title = 'مدیریت'

# تغییر URL Admin
admin.site.site_url = '/'

در سطح پروژه‌های بزرگ، یکی از تصمیم‌های مهم، محدودسازی دسترسی به Admin است. استفاده از AdminSite سفارشی روی یک URL غیرمعمول یا محدودسازی IP، از حملات خودکار جلوگیری می‌کند.

Django REST Framework و ساخت API

Django REST Framework (DRF) یکی از بالغ‌ترین ابزارهای ساخت API در دنیای پایتون است. این کتابخانه، ساخت APIهای RESTful حرفه‌ای را ساده می‌کند. اگر با مبانی REST آشنا نیستید، REST API چیست نقطه شروع مناسبی است.

Serializers. قلب DRF که تبدیل داده بین Model و JSON را مدیریت می‌کند:

from rest_framework import serializers
from .models import Order, OrderItem


class OrderItemSerializer(serializers.ModelSerializer):
    class Meta:
        model = OrderItem
        fields = ['id', 'product', 'quantity']


class OrderSerializer(serializers.ModelSerializer):
    items = OrderItemSerializer(many=True, read_only=True)
    user_email = serializers.EmailField(source='user.email', read_only=True)

    class Meta:
        model = Order
        fields = ['id', 'user_email', 'status', 'total', 'items', 'created_at']
        read_only_fields = ['id', 'created_at']

ViewSets و Routers. یکی از قابلیت‌های پیشرفته که CRUD را به چند خط کاهش می‌دهد:

from rest_framework import viewsets, permissions
from rest_framework.decorators import action
from rest_framework.response import Response
from .models import Order
from .serializers import OrderSerializer


class OrderViewSet(viewsets.ModelViewSet):
    serializer_class = OrderSerializer
    permission_classes = [permissions.IsAuthenticated]

    def get_queryset(self):
        return (
            Order.objects
            .filter(user=self.request.user)
            .select_related('user')
            .prefetch_related('items')
        )

    def perform_create(self, serializer):
        serializer.save(user=self.request.user)

    @action(detail=True, methods=['post'])
    def cancel(self, request, pk=None):
        order = self.get_object()
        order.status = 'cancelled'
        order.save()
        return Response({'status': 'cancelled'})

Authentication و Permission.

REST_FRAMEWORK = {
    'DEFAULT_AUTHENTICATION_CLASSES': [
        'rest_framework.authentication.SessionAuthentication',
        'rest_framework_simplejwt.authentication.JWTAuthentication',
    ],
    'DEFAULT_PERMISSION_CLASSES': [
        'rest_framework.permissions.IsAuthenticated',
    ],
    'DEFAULT_PAGINATION_CLASS': 'rest_framework.pagination.PageNumberPagination',
    'PAGE_SIZE': 20,
    'DEFAULT_THROTTLE_CLASSES': [
        'rest_framework.throttling.AnonRateThrottle',
        'rest_framework.throttling.UserRateThrottle',
    ],
    'DEFAULT_THROTTLE_RATES': {
        'anon': '20/hour',
        'user': '1000/day',
    },
}

Optimization. یکی از نکات کلیدی در DRF، کاهش تعداد کوئری‌هاست:

class OrderViewSet(viewsets.ModelViewSet):
    def get_queryset(self):
        return (
            Order.objects
            .select_related('user', 'payment')
            .prefetch_related(
                'items',
                'items__product',
            )
        )

در سطح پروژه‌های بزرگ، یکی از تصمیم‌های مهم، انتخاب بین ModelViewSet و APIView است. ModelViewSet برای منابع استاندارد مناسب است، در حالی که APIView برای منطق پیچیده انعطاف بیشتری دارد.

برای درک عمیق‌تر طراحی API، مرور اصول طراحی REST API چارچوب کاملی ارائه می‌دهد.

Celery و پردازش ناهمگام

Celery یکی از قدرتمندترین ابزارهای پردازش ناهمگام در دنیای پایتون است که عملیات زمان‌بر را از چرخه درخواست کاربر خارج می‌کند. Django به‌طور سنتی همگام است، اما با Celery می‌توان عملیات سنگین را در پس‌زمینه اجرا کرد.

پیکربندی پایه.

# config/celery.py
import os
from celery import Celery

os.environ.setdefault('DJANGO_SETTINGS_MODULE', 'config.settings.production')

app = Celery('myproject')
app.config_from_object('django.conf:settings', namespace='CELERY')
app.autodiscover_tasks()

تعریف Task.

# apps/orders/tasks.py
from celery import shared_task
from django.core.mail import send_mail


@shared_task(bind=True, max_retries=3)
def send_order_confirmation(self, order_id):
    try:
        from .models import Order
        order = Order.objects.get(id=order_id)

        send_mail(
            subject='تأیید سفارش',
            message=f'سفارش {order.id} ثبت شد.',
            from_email='noreply@example.com',
            recipient_list=[order.user.email],
        )
    except Exception as exc:
        raise self.retry(exc=exc, countdown=60)

اجرای Task.

# اجرای فوری در پس‌زمینه
send_order_confirmation.delay(order.id)

# اجرا با تأخیر
send_order_confirmation.apply_async(
    args=[order.id],
    countdown=60,
)

# زمان‌بندی
from datetime import timedelta
send_order_confirmation.apply_async(
    args=[order.id],
    eta=timezone.now() + timedelta(hours=24),
)

Celery Beat. سیستم زمان‌بندی داخلی Celery:

CELERY_BEAT_SCHEDULE = {
    'cleanup-expired-orders': {
        'task': 'apps.orders.tasks.cleanup_expired',
        'schedule': crontab(hour=3, minute=0),
    },
    'send-daily-report': {
        'task': 'apps.reports.tasks.send_daily',
        'schedule': crontab(hour=8, minute=0, day_of_week=1),
    },
}

Chains و Groups. یکی از قابلیت‌های پیشرفته Celery:

from celery import chain, group, chord


# Chain: اجرای ترتیبی
chain(
    process_payment.s(order.id),
    generate_invoice.s(),
    send_invoice_email.s(),
).apply_async()


# Group: اجرای موازی
group(
    send_email.s(user.id) for user in users
).apply_async()


# Chord: اجرای موازی با callback
chord(
    group(process_image.s(img.id) for img in images)
)(aggregate_results.s())

Monitoring با Flower. یکی از ابزارهای کلیدی برای نظارت:

pip install flower
celery -A config flower

Flower امکان مشاهده Taskهای در حال اجرا، موفق، شکست‌خورده و زمان‌بندی‌شده را فراهم می‌کند.

کش و بهینه‌سازی عملکرد

کش، یکی از مؤثرترین راه‌های بهبود عملکرد در Django است. این فریم‌ورک مجموعه‌ای از ابزارهای کش را ارائه می‌دهد که هر کدام برای سناریوی خاصی مناسب هستند.

پیکربندی Cache.

CACHES = {
    'default': {
        'BACKEND': 'django.core.cache.backends.redis.RedisCache',
        'LOCATION': 'redis://127.0.0.1:6379/1',
        'OPTIONS': {
            'CLIENT_CLASS': 'django_redis.client.DefaultClient',
        },
    }
}

سه سطح کش در Django.

سطح اول، View-level Cache. کش کردن کامل یک View:

from django.views.decorators.cache import cache_page


@cache_page(60 * 15)  # 15 دقیقه
def product_list(request):
    products = Product.objects.all()
    return render(request, 'products/list.html', {'products': products})

سطح دوم، Template Fragment Cache. کش کردن بخشی از قالب:

{% load cache %}

{% cache 600 sidebar request.user.id %}
    <aside>...</aside>
{% endcache %}

سطح سوم، Low-level Cache. کنترل کامل روی کش:

from django.core.cache import cache


def get_popular_products():
    products = cache.get('popular_products')

    if products is None:
        products = list(
            Product.objects
            .annotate(sales=Count('orders'))
            .order_by('-sales')[:10]
        )
        cache.set('popular_products', products, 3600)

    return products

Cache Invalidation. یکی از چالش‌های اصلی کش:

from django.db.models.signals import post_save
from django.dispatch import receiver
from django.core.cache import cache


@receiver(post_save, sender=Product)
def invalidate_product_cache(sender, instance, **kwargs):
    cache.delete('popular_products')
    cache.delete(f'product_detail_{instance.id}')

Query Optimization. علاوه بر کش، بهینه‌سازی کوئری‌ها نقش کلیدی دارد:

# استفاده از فقط ستون‌های ضروری
User.objects.only('id', 'email')

# Bulk operations
User.objects.bulk_create([...])
User.objects.bulk_update([...], ['status'])

# Aggregation در سطح دیتابیس
from django.db.models import Count, Avg, Sum

Product.objects.annotate(
    review_count=Count('reviews'),
    avg_rating=Avg('reviews__rating'),
)

برای درک عمیق‌تر بهینه‌سازی، بهینه‌سازی عملکرد بک‌اند چارچوب کاملی ارائه می‌دهد.

تست در پروژه‌های Django

تست، بخش جدایی‌ناپذیر هر پروژه حرفه‌ای Django است. فریم‌ورک ابزارهای قدرتمندی برای تست ارائه می‌دهد که در پروژه‌های بزرگ، به یک ضرورت تبدیل می‌شوند.

ساختار پایه تست.

from django.test import TestCase
from django.urls import reverse
from apps.orders.models import Order


class OrderViewTest(TestCase):
    def setUp(self):
        self.user = User.objects.create_user(
            username='test',
            password='test123',
        )
        self.client.login(username='test', password='test123')

    def test_order_list_displays_only_user_orders(self):
        other_user = User.objects.create_user(username='other')
        Order.objects.create(user=self.user)
        Order.objects.create(user=other_user)

        response = self.client.get(reverse('orders:list'))

        self.assertEqual(response.status_code, 200)
        self.assertEqual(len(response.context['orders']), 1)

Factory Pattern. یکی از الگوهای پرکاربرد برای ساخت داده تست:

# apps/orders/tests/factories.py
import factory
from apps.users.tests.factories import UserFactory
from apps.orders.models import Order


class OrderFactory(factory.django.DjangoModelFactory):
    class Meta:
        model = Order

    user = factory.SubFactory(UserFactory)
    status = 'pending'
    total = 100.00

استفاده در تست:

def test_multiple_orders(self):
    orders = OrderFactory.create_batch(5, user=self.user)
    self.assertEqual(Order.objects.count(), 5)

DRF API Tests. برای تست API:

from rest_framework.test import APITestCase


class OrderAPITest(APITestCase):
    def test_create_order_requires_authentication(self):
        response = self.client.post('/api/v1/orders/', {})
        self.assertEqual(response.status_code, 401)

    def test_create_order_authenticated(self):
        self.client.force_authenticate(user=self.user)
        response = self.client.post('/api/v1/orders/', {
            'product_id': 1,
            'quantity': 2,
        })
        self.assertEqual(response.status_code, 201)

Performance Tests. یکی از ابزارهای مهم برای اندازه‌گیری تعداد کوئری‌ها:

def test_order_list_query_count(self):
    OrderFactory.create_batch(10, user=self.user)

    with self.assertNumQueries(2):  # ۱ برای orders، ۱ برای user
        self.client.get(reverse('orders:list'))

این تست، از بازگشت مشکل N+1 در آینده جلوگیری می‌کند.

استقرار و ملاحظات تولید

استقرار پروژه Django در محیط تولید، نیازمند تصمیم‌های معماری مشخص است. تفاوت بین یک پروژه توسعه و یک پروژه تولید، در جزئیاتی است که اغلب نادیده گرفته می‌شوند.

تنظیمات تولید.

# config/settings/production.py
DEBUG = False
ALLOWED_HOSTS = ['example.com', 'www.example.com']

# Security
SECURE_SSL_REDIRECT = True
SESSION_COOKIE_SECURE = True
CSRF_COOKIE_SECURE = True
SECURE_HSTS_SECONDS = 31536000
SECURE_HSTS_INCLUDE_SUBDOMAINS = True

# Database
DATABASES = {
    'default': {
        'ENGINE': 'django.db.backends.postgresql',
        'NAME': os.environ['DB_NAME'],
        'USER': os.environ['DB_USER'],
        'PASSWORD': os.environ['DB_PASSWORD'],
        'HOST': os.environ.get('DB_HOST', 'localhost'),
        'CONN_MAX_AGE': 600,
    }
}

WSGI vs ASGI. یکی از تصمیم‌های مهم:

# WSGI (همگام)
gunicorn config.wsgi:application --workers 4 --threads 2

# ASGI (ناهمگام - برای WebSocket، Channels)
uvicorn config.asgi:application --workers 4

Static Files. یکی از نقاط پرهزینه در استقرار:

python manage.py collectstatic --no-input

# در settings
STATIC_ROOT = BASE_DIR / 'staticfiles'
STATIC_URL = '/static/'
STATICFILES_STORAGE = 'django.contrib.staticfiles.storage.ManifestStaticFilesStorage'

Logging. یکی از ضروریات محیط تولید:

LOGGING = {
    'version': 1,
    'disable_existing_loggers': False,
    'formatters': {
        'verbose': {
            'format': '{levelname} {asctime} {module} {message}',
            'style': '{',
        },
    },
    'handlers': {
        'file': {
            'level': 'INFO',
            'class': 'logging.handlers.RotatingFileHandler',
            'filename': BASE_DIR / 'logs/django.log',
            'maxBytes': 1024 * 1024 * 10,
            'backupCount': 5,
            'formatter': 'verbose',
        },
        'console': {
            'class': 'logging.StreamHandler',
            'formatter': 'verbose',
        },
    },
    'loggers': {
        'django': {
            'handlers': ['file', 'console'],
            'level': 'INFO',
            'propagate': True,
        },
    },
}

Docker. یکی از رایج‌ترین رویکردهای استقرار:

FROM python:3.11-slim

WORKDIR /app

COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt

COPY . .

CMD ["gunicorn", "config.wsgi:application", "--bind", "0.0.0.0:8000"]

Health Checks. یکی از ضروریات در محیط تولید:

# apps/core/views.py
from django.http import JsonResponse
from django.db import connection


def health_check(request):
    try:
        with connection.cursor() as cursor:
            cursor.execute('SELECT 1')
        return JsonResponse({'status': 'ok'})
    except Exception as e:
        return JsonResponse(
            {'status': 'error', 'detail': str(e)},
            status=503,
        )

دام‌های پنهانی که پروژه را زمین می‌زنند

در بازبینی پروژه‌های متعدد Django، مجموعه‌ای از دام‌های مشخص را دیده‌ام که بارها تکرار شده‌اند.

دام اول، Fat View. Viewهایی با صدها خط منطق که تست‌پذیری و نگهداشت را از بین می‌برند. راه‌حل: انتقال به Service.

دام دوم، N+1 Query. بارگذاری روابط بدون select_related یا prefetch_related که در مقیاس به فاجعه تبدیل می‌شود.

دام سوم، نبود Index. نبود Index روی ستون‌های پرکاربرد، کوئری‌ها را در مقیاس کند می‌کند.

دام چهارم، User پیش‌فرض بدون تصمیم. استفاده از User پیش‌فرض Django بدون در نظر گرفتن نیازهای آینده، مهاجرت پرهزینه‌ای را تحمیل می‌کند.

دام پنجم، نبود کش. در پروژه‌های پرترافیک، نبود استراتژی کش، سرور را در چند دقیقه از پا در می‌آورد.

دام ششم، Celery در چرخه درخواست. اجرای همگام Taskهای سنگین که تجربه کاربر را خراب می‌کند.

دام هفتم، نبود تست. پروژه بدون تست، در هر تغییری به یک ریسک تبدیل می‌شود.

دام هشتم، تنظیمات توسعه در تولید. باقی گذاشتن DEBUG=True در محیط تولید، یک آسیب‌پذیری جدی است.

دام نهم، مخلوط کردن منطق و نمایش. نوشتن کوئری‌های پیچیده در Template، کد را غیرقابل نگهداری می‌کند.

دام دهم، نبود مستندسازی. پروژه‌ای که مستند نباشد، در چند ماه به یک جعبه سیاه تبدیل می‌شود.

دام یازدهم، DRF بدون بهینه‌سازی. Serializerهایی که روابط را بدون select_related بارگذاری می‌کنند، تعداد کوئری‌ها را چند برابر می‌کنند.

دام دوازدهم، نادیده گرفتن Migrationها. تغییر مستقیم ساختار دیتابیس بدون Migration، هماهنگی تیم را از بین می‌برد.

برای درک عمیق‌تر این دام‌ها و راه‌های اجتناب از آن‌ها، مرور اشتباهات رایج در توسعه بک‌اند چارچوب کاملی ارائه می‌دهد.

پرسش‌های پرتکرار درباره Django

Django چیست و چه تفاوتی با Flask دارد؟ Django یک فریم‌ورک کامل با فلسفه Batteries Included است، در حالی که Flask یک فریم‌ورک سبک و مینیمال است که انعطاف بیشتری ارائه می‌دهد. اگر با این مقایسه آشنا نیستید، Flask سبک و انعطاف‌پذیر چارچوبی از این تصمیم ارائه می‌دهد.

ORM در Django چطور کار می‌کند؟ Django ORM هر جدول دیتابیس را به یک کلاس پایتون نگاشت می‌کند و عملیات را از SQL خالص به متدهای شیءگرا تبدیل می‌کند.

N+1 Query چیست و چطور حل می‌شود؟ N+1 زمانی رخ می‌دهد که برای هر رکورد یک کوئری اضافه زده شود. راه‌حل، استفاده از select_related برای ForeignKey و prefetch_related برای ManyToMany است.

چطور API در Django بسازم؟ با استفاده از Django REST Framework که Serializer، ViewSet و Router ارائه می‌دهد. برای درک عمیق‌تر، طراحی API در بک‌اند نقطه شروع مناسبی است.

Celery چه کاربردی دارد؟ Celery عملیات سنگین را از چرخه درخواست خارج می‌کند و در پس‌زمینه اجرا می‌کند. این کار، پاسخ سریع به کاربر و مقیاس‌پذیری بالا فراهم می‌کند.

چطور از XSS در Django جلوگیری کنم؟ خروجی Django Template به‌طور خودکار Escape می‌شود. استفاده از |safe فقط در موارد ضروری و با احتیاط.

Mass Assignment Protection چیست؟ در Django، استفاده از Serializer با فیلدهای مشخص، از این مشکل جلوگیری می‌کند.

چطور Django را برای RTL آماده کنم؟ با استفاده از LANGUAGE_CODE = 'fa' و USE_I18N = True، و تنظیم Direction در قالب.

تفاوت Function-Based View و Class-Based View چیست؟ FBV ساده‌تر و خواناتر است، CBV برای ساختارهای استاندارد کد کمتری می‌خواهد. انتخاب بر اساس پیچیدگی View.

چطور عملکرد Django را بهینه کنم؟ با select_related، prefetch_related، کش کردن کوئری‌ها، Celery برای عملیات سنگین، و Indexes مناسب.

آیا تست نوشتن ضروری است؟ برای پروژه‌های بزرگ، بله. تست‌ها از بازگشت باگ‌ها جلوگیری می‌کنند و بازآرایی کد را ایمن می‌سازند.

User سفارشی چطور بسازم؟ با ارث‌بری از AbstractUser یا AbstractBaseUser و تنظیم AUTH_USER_MODEL در settings. این تصمیم باید در ابتدای پروژه گرفته شود.

چطور در Django فایل آپلود کنم؟ با استفاده از FileField یا ImageField در مدل و مدیریت فرم در View. برای فایل‌های بزرگ، ذخیره در S3 یا فضای ابری توصیه می‌شود.

Django Channels چه کاربردی دارد؟ Channels امکان استفاده از WebSocket و ارتباط لحظه‌ای در Django را فراهم می‌کند. برای چت، داشبوردهای زنده و اعلان‌های آنی مناسب است.

چطور در Django چند زبان پشتیبانی کنم؟ با استفاده از i18n داخلی، تعریف فایل‌های ترجمه و تنظیم LANGUAGES و LOCALE_PATHS در settings.

چطور Django را برای مقیاس آماده کنم؟ با Cache (Redis)، Celery برای Taskها، Database Replication، و تفکیک سرویس‌های خواندن و نوشتن.

تفاوت DRF و Django Forms چیست؟ Forms برای فرم‌های HTML با اعتبارسنجی سمت سرور طراحی شده، در حالی که DRF Serializer برای تبدیل داده بین Model و JSON در API.

پرسشی که پیش از انتخاب Django باید پاسخ دهید

پیش از آنکه Django را به‌عنوان فریم‌ورک پروژه انتخاب کنید، یک پرسش بنیادین را از خودتان بپرسید: «آیا تیم من آماده است اصول معماری، تست، بهینه‌سازی و امنیت را از ابتدا رعایت کند، یا فقط به سرعت اولیه Django چشم دوخته است؟» اگر پاسخ اول است، Django یکی از بهترین انتخاب‌هاست. اگر پاسخ دوم است، احتمالاً در ماه ششم با بدهی فنی سنگینی روبه‌رو خواهید شد.

Django ابزارهای فوق‌العاده‌ای برای توسعه سریع ارائه می‌دهد، اما این ابزارها در دستان ناآشنا، به دام تبدیل می‌شوند. تفاوت بین پروژه‌ای که با Django موفق می‌شود و پروژه‌ای که شکست می‌خورد، در خود فریم‌ورک نیست؛ در نحوه استفاده از آن است. اگر تجربه‌ای از پروژه Django در مقیاس واقعی دارید — چه موفق و چه ناموفق — برای بازخورد ارزشمند است بدانید. مخصوصاً اگر با دام مشخصی روبه‌رو شده‌اید که راه‌حل خاصی برای آن پیدا کرده‌اید. تجربه‌ی خودتان را در دیدگاه‌ها بنویسید؛ همان راه‌حل‌ها می‌توانند به خواننده بعدی کمک کنند.