How melias198/shiftz works
1. Repository shape
- Shiftz is a single Django monolith organized into domain apps: accounts, cars, carts, categories, and orders.
- It is primarily a server-rendered web application rather than an API-first system.
2. Project shell
- The shiftz package holds the Django project wiring: settings, root URL routing, ASGI/WSGI entrypoints, and the default landing view.
- Shared site-level templates live in templates/, while global frontend assets live in static/.
3. Presentation layer
- Each app owns its own templates, which indicates page-by-page server-side rendering with Django templates.
- The UI is built from reusable base layout templates plus app-specific pages for browse, account, cart, and checkout flows.
4. Accounts subsystem
- accounts covers registration, sign-in, profile management, and customer/order-related pages.
- It also includes email verification and password-reset screens, plus a signals.py file that likely automates account lifecycle behavior.
- The templates suggest both regular user and seller/admin-facing account screens.
5. Catalog subsystem
- cars is the main product-catalog app: car listing, car detail pages, search, and filtering.
- categories provides taxonomy support for grouping or browsing cars by category/brand-type relationships.
6. Cart subsystem
- carts acts as the shopping basket layer between browsing and checkout.
- Its dedicated cart page suggests it stores selected items and prepares them for order submission.
7. Order and payment subsystem
- orders handles checkout, payment, order completion/failure, and order tracking.
- The presence of ssl.py and PaymentGatewaySettings migrations shows integration with SSL Commerce as the payment boundary.
- Order model migrations indicate the order lifecycle and payment/status fields have evolved over time.
8. Data model and persistence
- Persistence is backed by SQLite (db.sqlite3) for application data.
- Domain data is split by app through Django models and migrations, which is the main boundary for business state.
9. Media and static content
- Uploaded images are stored under media/photos/brands and media/photos/cars, so car/brand imagery is runtime content, not bundled assets.
- CSS, fonts, images, and JS in static/ are the shared presentation assets for the frontend.
10. Back-office/admin boundary
- Every major app has an admin.py, showing Django admin is used as an operational back-office for managing models.
- The account templates for uploading brands/cars and viewing admin order details imply a seller/admin workflow alongside the customer workflow.
11. Primary runtime flows
- Browse/search flow: browser → cars views/templates → catalog data from SQLite/media.
- Purchase flow: browser → carts → orders → SSL Commerce payment boundary → order confirmation/tracking.
- Account flow: browser → accounts → authentication/verification/password reset → profile and order history.
12. Key architectural boundary
- The app boundary is centered on Django views/forms/models: views orchestrate pages, forms validate input, models own domain state, and templates render results.
- External dependencies only become visible at the payment and identity edges, while the rest of the system stays self-contained inside Django.
Main entry points: orders Orders · shiftz shiftz · accounts Accounts · cars Cars
Components 18
Project shell
Django wiring and shared site entrypoints
- shiftz · Settings, root URLs, ASGI/WSGI, and landing view
shiftz
Presentation
Server-rendered templates and shared static assets
- Base pages · Site-wide layout and landing page templates
templates - Static assets · Shared CSS, JS, fonts, and images
static
Domain apps
Core business subsystems organized as Django apps
- Accounts · Registration, login, profile, verification, and account pages
accounts - Account pages · Sign-in, sign-up, profile, admin, reset, and verification screens
accounts/templates/accounts - Account signals · Automated account-side behavior and notifications
accounts/signals.py - Cars · Car listing, detail, search, and filtering
cars - Catalog pages · Browse, detail, search, and filter views for cars
cars/templates/cars - Categories · Car grouping and category relationships
categories - Carts · Shopping basket and item selection before checkout
carts - Cart page · Cart review and handoff to checkout
carts/templates/carts - Orders · Checkout, payment, completion, tracking, and order history
orders - Order pages · Place order, completion, failure, and tracking screens
orders/templates/orders - SSL Commerce · External payment integration surfaced through order processing
orders/ssl.py - Django admin · Model administration across the major apps
Data & runtime
Persistence and uploaded media
- SQLite DB · Primary persistence for Django models and migrations
db.sqlite3 - Media uploads · Brand and car photos stored under media/
media - Domain models · App-owned models and migrations define business state
Connections 27
- shiftz → Base pages: renders · Project landing and shared layout use base templates
- shiftz → Static assets: serves · Django serves shared static presentation assets
- shiftz → Accounts: routes · Root project dispatches into account flows
- shiftz → Cars: routes · Root project dispatches into catalog flows
- shiftz → Carts: routes · Root project dispatches into cart flows
- shiftz → Orders: routes · Root project dispatches into checkout flows
- Accounts → Account pages: renders · Account views render dedicated auth/profile templates
- Accounts → Account signals: triggers · Lifecycle hooks support verification and account automation
- Accounts → Domain models: uses · Account state is persisted through app models and migrations
- Cars → Catalog pages: renders · Catalog views render browse/search/detail pages
- Cars → Categories: groups by · Catalog browsing is organized by categories
- Cars → Media uploads: reads · Car and brand images are runtime content
- Cars → Domain models: uses · Catalog data is defined in app models and migrations
- Categories → Domain models: uses · Taxonomy state is stored in app models and migrations
- Carts → Cart page: renders · Basket views render the cart page
- Carts → Orders: hands off to · Cart contents move into checkout and order placement
- Carts → Domain models: uses · Cart state is persisted through app models and migrations
- Orders → Order pages: renders · Checkout, order completion, failure, and tracking pages
- Orders → SSL Commerce: integrates · Payment processing crosses into SSL Commerce
- Orders → Domain models: uses · Order lifecycle and payment status live in models and migrations
- Domain models → SQLite DB: persists to · Django models and migrations store state in SQLite
- Django admin → Accounts: manages · Admin workflows cover account data and operations
- Django admin → Cars: manages · Admin workflows cover catalog data and uploads
- Django admin → Orders: manages · Admin workflows cover order review and tracking
- Django admin → Categories: manages · Admin workflows cover taxonomy data
- Domain models → Media uploads: references · Model records point to uploaded brand and car photos
- Accounts → Orders: shows history · Account pages surface order history and details