jbocciadev/pp5-crafty

1. Overall shape

Crafty is a Django 3.2 monolith built around server-rendered pages, not a separate frontend/backend split. The project is divided into feature apps, each owning its own models, views, forms, URLs, templates, and tests.

2. Request routing

The crafty/urls.py project router delegates to six main domains: home, products, bag, checkout, profiles, and contact. This is the primary architectural boundary for user-facing functionality.

3. Core domain: product catalog

The products app is the catalog subsystem. It models categories, age groups, topics, products, and reviews. It also contains product management flows such as add/edit product pages, product detail pages, and review submission/editing. A custom widget and template tags support richer form rendering and rating display.

4. Cart subsystem

The bag app is a session-backed shopping cart. It is responsible for add/update/remove item actions, bag totals, and the checkout entry point. Its template tags and partial templates are used to render item summaries consistently across product and bag pages.

5. Checkout and payment boundary

The checkout app owns purchase finalization. It contains the Order and order line item models, checkout form, checkout page, success page, and Stripe integration. The JavaScript in checkout/static/checkout/js/stripe_elements.js drives card collection, while webhooks.py and webhook_handler.py handle payment event reconciliation on the server side. This app is the boundary between the site and the external payment processor.

6. User accounts and profiles

Authentication is handled through Django allauth, with custom templates overriding the default auth UI. The profiles app extends the built-in user with a UserProfile model for delivery/contact details and exposes a profile page with order history and profile management forms. This app is the user account boundary for personal data and post-purchase history.

7. Contact and newsletter

The contact app manages customer contact submissions and newsletter subscribers. It includes an unsubscribe flow and likely sends notification emails to the support mailbox and confirmation emails to the user. This is separate from checkout communications and acts as the site’s general inbound communication channel.

8. Public pages and shared site shell

The home app provides the landing page, while the global templates/ directory supplies shared layout and reusable UI fragments: main navigation, desktop/mobile footers, modal dialogs, and toast notifications. These shared templates are the presentation layer used across all apps.

9. Data model relationships

The system centers on a few key relational flows: users own profiles; products belong to catalog taxonomies; reviews attach users to products; orders own line items; order history is surfaced back into profiles. This creates a clean separation between browse, cart, and fulfillment data.

10. Static and media handling

Static CSS/JS lives under each app or in the global static/ directory. Media assets, including product images and site imagery, are stored separately and the repo includes custom_storages.py, indicating custom storage configuration for production media/static hosting.

11. Infrastructure and deployment

The app is deployed on Heroku with Gunicorn as the WSGI server. Production data is stored in PostgreSQL via ElephantSQL, and the app uses environment variables for secrets and service credentials. The README and config files indicate AWS S3 integration for static/media storage.

12. External service integrations

The two main external integrations are Stripe for payments and email delivery for confirmations/notifications. Django allauth provides account management, while Stripe webhooks provide a trusted asynchronous payment confirmation path after checkout submission.

13. Operational and cross-cutting concerns

The repo includes custom error pages, sitemap and robots files for SEO, and Django admin customizations for staff operations. Migrations are present for each app, and the included tests show that each subsystem is meant to be validated independently.

14. In practical diagram terms

A useful architecture diagram would show: browser requests into Django; Django dispatching into feature apps; shared templates/static supporting all apps; checkout branching out to Stripe and email; and persistence flowing into PostgreSQL and AWS-backed media/static storage. The main trust boundary is the checkout/payment path, followed by auth/profile data and contact/newsletter messaging.