Skip to content

System Mental Model

This section explains how this system is designed to think and behave at a conceptual level.

Before reading any app-level documentation, it is important to understand:

  • What the platform is fundamentally built for
  • Which entities define the business
  • How customer and seller roles coexist
  • Why certain constraints and flows exist

After this section, you should be able to understand the system without opening the code.

What This System Actually Is

At its core, this project is a digital product selling platform with a strong focus on:

  • Lifetime access to purchased products
  • Product-centric customer journeys
  • Paid, repeatable post-purchase support
  • Seller-first operational tooling

This is not a generic ecommerce system. It is designed specifically for selling and maintaining digital products over time.

Core Business Entities

The entire platform revolves around three core business entities:

  • Product
  • PurchasedProduct
  • SupportRequest

Everything else in the system exists to enable, support, or extend these three entities.

Supporting entities include:

  • User
  • Order
  • Payment
  • ProductCategory
  • ShortURL
  • Analytics / Metrics

Supporting entities are important, but they do not define the business on their own.

Center of Gravity: Product

The Product is the center of gravity of the system.

  • Products exist before users purchase anything
  • Products can exist without orders or payments
  • All revenue, access, and support flows start from a product

If you remove:

  • Users → products still make sense
  • Orders → products still make sense
  • Payments → products still make sense

But if you remove Product, the system loses its purpose.

Every major feature in this project either:

  • helps sell a product
  • grants access to a product
  • supports a product after purchase

This explains why many design decisions are product-first, not user-first.

Customer and Seller Are Roles, Not Separate Systems

A key mental model to understand:

A seller is also a customer in this system.

  • Sellers can purchase products
  • Sellers have access to My Products and My Supports
  • Seller-specific capabilities are additive, not separate

This means:

  • There is one core product experience
  • Seller functionality is layered on top of the same foundation

This avoids duplication and keeps the system consistent.

PurchasedProduct: Access Is the Real Asset

The PurchasedProduct entity represents access, not just a transaction.

Key truths:

  • A PurchasedProduct cannot exist without payment
  • PurchasedProduct grants lifetime access
  • When a product is updated:
  • The same PurchasedProduct remains valid
  • The user can re-download the latest version
  • No additional payment is required

This is why PurchasedProduct is treated as a core entity, not a derived one.

Support Is Strictly Post-Purchase and Paid

Support in this system follows strict rules:

  • A SupportRequest cannot exist without a PurchasedProduct
  • Support is not free
  • A customer can raise multiple support requests for the same product
  • Each support request is treated as an independent, chargeable unit

Support exists to:

  • Help with setup
  • Assist with deployment
  • Handle product-specific issues

It is intentionally decoupled from the purchase itself.

Entity Existence Rules (High-Level Constraints)

These constraints shape validation and flow logic across the system:

  • A User can exist without purchasing anything
  • A Product can exist without being sold
  • A PurchasedProduct cannot exist without successful payment
  • A SupportRequest cannot exist without a PurchasedProduct
  • A ShortURL can exist independently of Products

Understanding these rules helps avoid incorrect assumptions while extending the system.

Ownership and Responsibility Model

This project follows a clear rule:

Each app owns its own data and behavior.

However, unlike rigid architectures:

  • Multiple apps may write to related entities
  • This is intentional and driven by real business workflows

Ownership still exists, but flows matter more than isolation.

This flexibility allows:

  • Payment systems to update access
  • Support systems to update request states
  • Seller tools to extend product behavior

Later sections will clearly document safe vs risky write paths.

System Boundaries

This platform considers the following as part of the system:

  • Business logic
  • Authentication and role-based access
  • Purchase lifecycle
  • Product access and updates
  • Paid support workflows
  • Integrations (payments, analytics, storage)

The system is not just a backend — it is a complete product platform.

Customer Lifecycle Is the Backbone

This is a product-first system, driven by the customer lifecycle:

  • Discover product
  • Login / Register
  • Purchase product
  • Access granted (PurchasedProduct)
  • Download & updates
  • Paid support (SupportRequest)
  • Long-term usage

If you ever feel lost in the codebase, come back to this lifecycle.

Almost every design decision maps back to it.

How This Mental Model Should Be Used

From this point onward:

  • Section 3 will explain real business flows across apps
  • Section 5 will deep dive into apps and files
  • Every app explanation will reference this mental model

If something feels confusing later, it usually means:

you are looking at implementation details without revisiting system intent