🏗️ CakePlanner Architecture

This document provides a high-level overview of the CakePlanner architecture, covering the system design, domain boundaries, and key technical workflows.

Description

The Cake Planner is a web-based application designed to organize cake-bringing events within groups (e.g., teams, departments). It consists of a modern Single Page Application (SPA) frontend and a high-performance C++ backend.

1. System Context (The Big Picture)

The Cake Planner is designed as a monolithic application that serves baking groups (companies, clubs, friends) to organize events. It acts as the central hub for planning, rating, and sharing photos.

The system follows a classic **Client-Server Architecture**, facilitated by a Reverse Proxy.

The following C4-style System Context diagram illustrates how users interact with the system and how the internal components relate to each other.

2. Container Architecture

The system consists of a modern Single Page Application (SPA) frontend and a high-performance C++ backend.

Component Description

1. NGINX (Reverse Proxy & Web Server)

The entry point for all traffic. It handles:

• SSL Termination: Manages HTTPS certificates and encryption.
• Static File Serving: Delivers the compiled Angular application (HTML, CSS, JS) directly to the browser.
• Reverse Proxy: Forwards all requests starting with `/api/` to the C++ Backend.
• Security Headers: Adds headers like CSP, HSTS, and X-Frame-Options.

2. Frontends (Angular App)

Admin-Panel: A Single Page Application (SPA) built with Angular.

• Runs in the user's browser.
• Communicates with the Backend via REST API.
• Handles Groups, Users, Assignments, and Settings.

User-App: A Progressive Web Application (PWA) built with Angular.

• Runs in the user's browser.
• Communicates with the Backend via REST API.
• Handles logic for views, routing, and user interaction.

3. Backend (C++ Crow)

The core logic provider, written in C++23 using the Crow framework.

• REST API: Provides endpoints for managing users, events, and ratings.
• Authentication: Validates JWT tokens and handles login/registration.
• Business Logic: Enforces rules (e.g., "only owners can delete future events").
• Image Processing: Uses Qt to resize and convert uploaded images to WebP.

4. Database (SQLite)

A local, file-based relational database.

• Stores all structured data (users, events, groups, ratings).
• Ensures data integrity via Foreign Keys.
• Lightweight and requires no separate server process.

5. External Systems

SMTP Mail Gateway: Used by the backend to send notifications (registration, password reset, event updates).

3. Domain Design (Bounded Contexts)

The Cake Planner system is divided into several Bounded Contexts to modularize logic and clarify responsibilities. This ensures that different parts of the system (e.g., user management vs. event planning) remain loosely coupled where possible.

3.1 Bounded Contexts Description

1. Identity & Access Management (IAM)

Responsibility: Handles everything related to checking "who is this user" and "what can they do".

• Core Entities: `User`, `Credentials`, `Token`.
• Key Processes: Registration, Login (JWT), Password Reset (Forgot Password), Two-Factor Authentication (2FA).

2. Group Management

• Responsibility: Manages the organizational structures where events happen.
• Core Entities: `Group`, `Membership` (Role: Admin/Member).
• Key Processes: Creating groups, inviting members, assigning roles.

3. Event Planning

• Responsibility: The core domain of the application; scheduling and organizing cake events.
• Core Entities: `Event`, `Baker` (User alias), `Schedule`.
• Key Processes: Creating an event ("I bring cake"), deleting events, viewing the calendar.

4. Engagement & Social

• Responsibility: Increases user interaction and adds fun to the platform.
• Core Entities: `Rating`, `Comment`, `GalleryPhoto`.
• Key Processes: Rating a cake (1-5 stars), uploading photos of the cake.

5. Notification System

• Responsibility: Asynchronous communication with external world.
• Core Entities: `Notification`, `EmailTemplate`.
• Key Processes: Sending activation emails, event reminders, and change alerts.

3.2 Context Map Diagram

The following diagram illustrates the relationships between these contexts. To maintain readability, the components are arranged hierarchically.

3.3 Distinct Bounded Contexts

To keep the logic organized, the application is conceptually divided into distinct Bounded Contexts. Each context handles a specific part of the business domain.

🔎 Context Descriptions

1. Identity & Access: Handles user registration, login, and group assignments. Ensures that only group members can see their events.

2. Planning: The core calendar logic. Manages dates, baker assignments, and prevents scheduling conflicts.

3. Engagement: Contains the logic for the "Hall of Fame". It calculates average ratings and sorts events by popularity.

4. Media: A specialized technical context responsible for handling file uploads, generating thumbnails, and optimizing images for the web (WebP).

5. Administration: Provides tools for system maintainers to manage users, reset passwords, configure global settings, and view system logs.