Skip to content

Cross-App Dependency Map

This section explains how apps depend on each other , why those dependencies exist , and what is allowed vs forbidden in this architecture.

The goal is to understand:

  • where data originates
  • how responsibilities are split
  • which app owns which concept
  • where changes are safe and where they are risky

This is the mental wiring diagram of the system.

The Core Design Rule

Each app owns its own data and business rules.

Other apps may depend on that data, but never own it.

This means:

  • Models belong to exactly one app
  • State transitions are controlled by the owning app
  • Cross-app access is always read or orchestrate , never redefine

This rule is consistently followed across the project.

High-Level Dependency Direction

The overall dependency direction is top-down , not circular:

users
  ↓
seller ────────────┐
  ↓                │
payments           │
  ↓                │
payments_dodo      │
  ↓                │
PurchasedProduct◄──┘
  ↓
depsupportcore / customer / shorturl
(read-only consumers)

Key idea:

  • Business state flows forward
  • UI apps consume, never mutate core business state

Central Backbone: User → Product → Order → PurchasedProduct

These four models form the backbone of the entire system .

Ownership

Concept Owning App
User users
Product seller
Order payments
PurchasedProduct payments

Everything else in the system either:

  • reads from these models, or
  • reacts to state changes in these models

App-to-App Dependency Table

This table shows who depends on whom, and why .

App Depends On Reason
core seller, payments Show products, check purchase state
auth_email users Authentication, email verification
seller users, payments, depsupport Seller dashboard, revenue, support handling
customer users, payments, depsupport Customer panel, downloads, support
payments users, seller Create orders for products
payments_dodo payments, seller, users Payment orchestration
depsupport payments Support must be tied to PurchasedProduct
shorturl users URL ownership & analytics
under_construction none (global) Middleware-level system control

Important:

  • No app bypasses the Order → PurchasedProduct rule
  • Support always depends on ownership (PurchasedProduct)

Why PurchasedProduct Is the Pivot Model

PurchasedProduct is the single source of truth for access.

It is intentionally designed this way:

  • A user can exist without purchases ✔
  • A product can exist without orders ✔
  • An order can exist without payment ✔
  • PurchasedProduct exists only when payment succeeds ❗

Used by:

  • payments → access grant
  • customer → downloads
  • seller → customer count
  • depsupport → support eligibility

This prevents:

  • fake access
  • manual hacks
  • inconsistent permission checks

Support System Dependency Boundary

The support system (depsupport) has one strict dependency rule :

No PurchasedProduct → No SupportRequest

Enforced at:

  • model level
  • view level
  • UI level

This ensures:

  • support is always tied to revenue
  • no free or orphaned support requests
  • seller workload stays controlled

Payment Dependency Separation

Payment logic is intentionally split :

payments

  • owns Order
  • owns PurchasedProduct
  • defines what payment success means

payments_dodo

  • talks to external provider
  • handles checkout + webhook
  • never decides access on its own

Access is granted only when :

Webhook → Order.is_paid = True → PurchasedProduct created

This separation allows:

  • Stripe / Razorpay later
  • parallel payment providers
  • zero rewrite of business logic

UI Apps Are Consumers, Not Owners

Apps like:

  • core
  • customer
  • seller

do not own business rules .

They:

  • read data
  • render state
  • trigger flows

But they never :

  • mark orders paid
  • grant access
  • create PurchasedProduct manually

This keeps the system safe from UI-level bugs.

Global Control: under_construction

under_construction sits outside normal app dependency rules .

Characteristics:

  • Middleware-level
  • Cached
  • Bypass via secret key
  • Admin-controlled

It can:

  • block everything
  • except staff and bypassed sessions

No other app depends on it directly.

What This Dependency Map Protects You From

This architecture prevents:

  • circular imports
  • “magic” access bugs
  • accidental free downloads
  • support without purchase
  • payment provider lock-in

And enables:

  • safe customization
  • predictable debugging
  • onboarding new developers easily