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

دلیل این حساسیت چیست؟ تغییر مدل کاربر در میانه مسیر معمولاً به یک چالش فنی پیچیده تبدیل می‌شود و می‌تواند فرآیند توسعه را با دردسرهای جدی روبه‌رو کند. به همین دلیل، توسعه‌دهندگان باتجربه از همان ابتدای پروژه، زیرساخت احراز هویت را بر پایه یک Custom User Model طراحی می‌کنند تا در آینده با محدودیت‌های غیرضروری مواجه نشوند.

پیش از اجرای اولین migrate این مرحله را انجام دهید

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

برای این کار، کافی است مقدار AUTH_USER_MODEL را در فایل settings.py به مدل سفارشی خود (برای مثال: "account.User") تنظیم کنید. اگر این مرحله را نادیده بگیرید و ابتدا migrate اولیه را اجرا کنید، جنگو جداول پیش‌فرض کاربر را ایجاد خواهد کرد. در چنین شرایطی، جایگزین کردن آن‌ها در ادامه پروژه معمولاً به فرایندی پیچیده، زمان‌بر و پرهزینه تبدیل می‌شود.

«تغییر مدل کاربر بعد از اجرای migrate اولیه، یک کابوس وقعی برای دیتابیس است. این کار ریسک بسیار بالایی در تخریب روابط بین جداول (Constraintها) و از دست رفتن یکپارچگی داده‌ها دارد.»

معماری صحیح با ایجاد اپلیکیشن اختصاصی account

برای داشتن یک پروژه مقیاس‌پذیر، مدیریت کاربران را در یک اپلیکیشن مستقل (مانند account) ایزوله کنید. این کار سه مزیت استراتژیک دارد:

1. معماری تمیزتر: جداسازی منطق احراز هویت (Authentication) از هسته اصلی بیزنس پروژه.

2. نگهداری آسان‌تر: متمرکز شدن کدهای مربوط به پروفایل و دسترسی‌ها در یک نقطه واحد.

3. جلوگیری از وابستگی‌های چرخه‌ای (Circular Dependency): با تعریف مدل کاربر در یک اپ مجزا و استفاده از ارجاع رشته‌ای settings.AUTH_USER_MODEL در مدل‌های دیگر، از قفل شدن ایمپورت‌های پایتون جلوگیری می‌کنید. در واقع این رشته به عنوان یک “نقطه مرجع واحد” عمل می‌کند که مانع از درگیری مستقیم کلاس‌ها با یکدیگر می‌شود.

تفاوت بین AbstractUser و AbstractBaseUser

اگرچه روش‌هایی مثل Proxy Model (برای تغییر رفتار) یا OneToOne Profile (برای افزودن اطلاعات جانبی) وجود دارند، اما راهکار استاندارد و حرفه‌ای، ارث‌بری از کلاس‌های انتزاعی جنگو است.

از کدام استفاده کنیم؟ AbstractUser یا AbstractBaseUser ؟

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

استفاده از AbstractUser

این انتخاب هوشمندانه برای 90% پروژه‌ها (SaaS، ربات‌ها و سیستم‌های مدیریت محتوا) است. شما تمام فیلدهای استاندارد (username، email، نام و…) را به ارث می‌برید و فقط فیلدهای خودتان (مثل شماره موبایل) را اضافه می‌کنید. این روش سازگاری کامل و بی‌دردسری با UserAdmin در پنل ادمین دارد.

روش AbstractBaseUser

این مسیر برای سیستم‌های خاصی است که نیاز به بازطراحی کامل دارند (مثلاً حذف کامل username و جایگزینی email به عنوان شناسه اصلی).

هشدار: در این روش، جنگو شما را مجبور می‌کند که یک BaseUserManager اختصاصی بنویسید و متدهای create_user و create_superuser را دستی پیاده‌سازی کنید. این کار کنترل کامل به شما می‌دهد، اما هزینه نگهداری و کدنویسی بالاتری دارد.

مقایسه فنی بین استفاده از AbstractUser و AbstractBaseUser

اشتباه رایج: استفاده مستقیم از مدل User در پروژه‌های Django

یکی از خطاهای متداول در توسعه پروژه‌های Django، وارد کردن مستقیم مدل پیش‌فرض کاربر با دستور:

from django.contrib.auth.models import User

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

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

روش استاندارد و قابل اعتماد

• 1- در بخش‌های منطقی برنامه، سرویس‌ها و Unit Testها بهتر است همیشه از تابع get_user_model() استفاده کنید. این تابع مدل کاربر فعال پروژه را بر اساس تنظیمات Django پیدا کرده و به صورت پویا در اختیار شما قرار می‌دهد.

# ./blog/models.py

from django.contrib.auth import get_user_model

User = get_user_model()

class Article(models.Model):
    # فیلد های دیگر...
    author = models.ForeignKey(User, null=True, on_delete=models.SET_NULL, related_name='articles')
    # فیلد های دیگر...

• 2- هنگام ایجاد ارتباط بین مدل‌ها، مانند تعریف فیلدهای ForeignKey یا ManyToMany، نباید کلاس User را مستقیماً وارد کنید. به جای آن از settings.AUTH_USER_MODEL به شکل یک رشته استفاده کنید.

# ./blog/models.py

from django.conf import settings


class Article(models.Model):
    # فیلد های دیگر...
    author = models.ForeignKey(settings.AUTH_USER_MODEL, null=True, on_delete=models.SET_NULL, related_name='articles')
    # فیلد های دیگر...

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

چک‌ لیست نهایی برای جلوگیری از اشتباهات حیاتی

پیش از نهایی کردن ساختار کاربران در پروژه جنگو، بررسی کنید که موارد زیر بدرستی انجام شده باشند:

تنظیم AUTH_USER_MODEL

آیا قبل از اجرای اولین makemigrations، مدل کاربر سفارشی خود را در فایل settings.py معرفی کرده‌اید؟ انجام ندادن این کار در ابتدای پروژه می‌تواند در آینده باعث مشکلات پیچیده‌ای در Migrationها شود.

تعریف USERNAME_FIELD

اگر از AbstractBaseUser استفاده کرده‌اید، آیا فیلدی که قرار است برای ورود کاربران استفاده شود را مشخص کرده‌اید؟ نبودن این تنظیم باعث می‌شود فرآیند احراز هویت به‌درستی کار نکند.

پیاده‌سازی Manager اختصاصی

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

ایجاد ایندکس مناسب

اگر ورود کاربران با ایمیل یا شماره موبایل انجام می‌شود، بهتر است روی این فیلدها محدودیت unique=True و ایندکس db_index=True را در نظر بگیرید تا هم از داده‌های تکراری جلوگیری شود و هم جستجو سریع‌تر انجام شود.

جمع‌بندی

تصمیم امروز، مسیر آینده پروژه را مشخص می‌کند.

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

فرقی نمی‌کند سادگی AbstractUser را انتخاب کنید یا کنترل کامل‌تر AbstractBaseUser را ترجیح دهید؛ نکته مهم این است که این تصمیم‌ها باید پیش از اولین Migration نهایی شوند. تغییر مدل کاربر پس از شروع توسعه پروژه می‌تواند به یکی از پرهزینه‌ترین تغییرات در ساختار دیتابیس تبدیل شود.

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