Skip to content

App-by-App Deep Dive

This section explains each Django app in isolation , while clearly stating:

  • what the app owns
  • what it is allowed to do
  • what it must never do
  • how it collaborates with other apps

Read this section app-by-app, not file-by-file.

The goal is architectural understanding , not API memorization.

users App – Identity & Roles (System Root)

Primary Responsibility

The users app owns identity, roles, and authentication state .

It is the root app of the entire system.

Owns

  • User model
  • Authentication identity (email-based)
  • Role flags:
  • is_customer
  • is_seller
  • is_staff
  • Email verification state

Does NOT Own

  • Products
  • Orders
  • Payments
  • Support
  • Any business workflow

Key Design Decisions

  • Email is the USERNAME_FIELD
  • One user can be:
  • only customer
  • only seller
  • both
  • No separate Seller/Customer tables → avoids duplication

Important Files

  • models.py

Custom user model with role flags. This choice enables:

  • shared login
  • shared profile
  • clean role-based panels
  • admin.py

Shows PurchasedProduct inline → visibility, not ownership * views.py (Generic views)

  • GenericUserProfileView
  • GenericPasswordChangeView
  • GenericOrderHistoryView
  • GenericMyProductListView

These views are abstract base views reused by:

  • customer
  • seller

Customization Notes

Safe:

  • Add new user fields
  • Add new role flags

Risky:

  • Changing authentication logic
  • Removing role flags
  • Modifying generic views without checking both panels

auth_email App – Authentication & Email Flows

Primary Responsibility

Handles how users log in, register, verify email, and reset passwords .

Owns

  • Login
  • Registration
  • Email verification
  • Password reset
  • Email sending via Celery

Does NOT Own

  • User model
  • Role logic
  • Redirect destinations (delegates to roles)

Key Design Decisions

  • Uses Django auth + custom views
  • Uses Celery for all emails (non-blocking)
  • Google OAuth integrated via social_django

Important Files

  • views.py
  • LoginView → role-based redirect
  • RegistrationView → auto-login
  • Email verification & reset views
  • tasks.py
  • send_email_task (retry-safe)
  • utils.py
  • Thin helper layer (no logic duplication)

Customization Notes

Safe:

  • Change email templates
  • Add new OAuth providers

Risky:

  • Changing redirect logic
  • Removing Celery from emails

core App – Public Website Layer

Primary Responsibility

The public-facing website :

  • Home page
  • Product listing
  • Product detail

Owns

  • No core business models
  • Only presentation logic

Reads From

  • seller.Product
  • seller.ProductCategory
  • payments.PurchasedProduct (read-only)

Key Design Decisions

  • No login required for browsing
  • Purchase state is derived, not stored
  • No write operations

Important Files

  • views.py
  • HomePageView
  • ProductListView (search + category filter)
  • ProductDetailView (purchase-aware)

Customization Notes

Safe:

  • UI/UX changes
  • Filters and pagination

Risky:

  • Adding write logic
  • Creating orders from here

seller App – Product & Revenue Owner

Primary Responsibility

Everything related to selling digital products .

Owns

  • Product
  • ProductCategory
  • Seller dashboard
  • Seller analytics (revenue, buyers)

Does NOT Own

  • Orders
  • Payments
  • Access control

Key Design Decisions

  • Seller == User with is_seller=True
  • Product lifecycle:
  • draft → published → updated
  • Slug auto-generation via signals

Important Files

  • models.py
  • Product
  • ProductCategory
  • signals.py
  • Slug generation
  • Selling price fallback
  • views.py
  • Dashboard
  • Product CRUD
  • Category CRUD

Critical Rules

  • Product cannot be deleted if purchased
  • Product updates trigger:
  • update badge
  • payment provider sync

Customization Notes

Safe:

  • Add product fields
  • Add new dashboard metrics

Risky:

  • Deleting signals
  • Allowing product deletion with purchases

payments App – Order & Access Authority

Primary Responsibility

Defines what it means to buy something .

Owns

  • Order
  • PurchasedProduct

Key Design Decisions

  • Orders exist even if payment fails
  • Access is granted only via PurchasedProduct
  • Lifetime access model

Important Files

  • models.py
  • Order
  • PurchasedProduct
  • views.py
  • Download logic
  • Signed URL generation

Security Design

  • Local dev → filesystem
  • Production → presigned S3 URLs (10 min expiry)

Customization Notes

Safe:

  • Add new order states
  • Add refunds logic

Risky:

  • Granting access without payment
  • Bypassing PurchasedProduct

payments_dodo App – External Payment Orchestrator

Primary Responsibility

Connects business payments with Dodo (MoR) .

Owns

  • Dodo customer mapping
  • Dodo product mapping
  • Checkout initiation
  • Webhook processing

Does NOT Own

  • Order state meaning
  • Access rules

Key Design Decisions

  • Signals create/update Dodo entities
  • Webhook is the single source of truth
  • Atomic transactions

Important Files

  • signals.py
  • views.py (checkout + webhook)

Customization Notes

Safe:

  • Add new payment providers as separate apps

Risky:

  • Editing webhook logic
  • Removing atomic blocks

customer App – Customer Panel Layer

Primary Responsibility

Customer-facing dashboard.

Owns

  • Nothing (UI-only)

Uses

  • Generic views from users
  • Read-only access to:
  • PurchasedProduct
  • Orders
  • Support requests

Key Design Decisions

  • Role-based access via mixins
  • Same backend as seller (shared logic)

Customization Notes

Safe:

  • UI changes
  • New customer-only views

Risky:

  • Business logic additions

depsupport App – Paid Support Workflow

Primary Responsibility

Manages post-purchase paid support .

Owns

  • SupportRequest
  • Support state machine

Depends On

  • payments.PurchasedProduct

Key Design Decisions

  • Support is never free
  • One active request per product
  • Seller controls progression
  • No Limit of availing support

Important Files

  • models.py (status machine)
  • tasks.py (Telegram notifications)

Customization Notes

Safe:

  • Add new statuses
  • Change notification channels

Risky:

  • Allowing support without purchase

shorturl App – Utility Tool

Primary Responsibility

Seller utility for shareable URLs .

Owns

  • Shorturl

Key Design Decisions

  • Cached redirects
  • Expiry support
  • Destination can change

Customization Notes

Safe:

  • Analytics extensions

Risky:

  • Removing expiry checks

under_construction App – Global Kill Switch

Primary Responsibility

System-wide maintenance mode .

Design

  • Middleware-based
  • Cached
  • Bypass via secret key

Customization Notes

Safe:

  • UI changes

Risky:

  • Removing middleware safeguards