hossain-arafat/pizzago

1. What this repository is

PizzaGo is a PHP/MySQL restaurant ordering system built around an MVC split: browser-facing PHP views, request-handling controllers, and database models. It is not a single-page app; each interaction is a server-rendered request/response cycle.

2. Application entry and request routing

index.php is the top-level entry point. From there, the app presents the landing/auth flow and delegates feature actions to dedicated controllers. The architecture suggests standard PHP page navigation rather than a framework router.

3. Presentation layer

The view/ directory contains the rendered pages for customer, staff, and admin workflows: login/signup, menu/cart, dashboard, orders, profile, pizza management, staff management, and password recovery. Shared UI chrome lives in header.php, footer.php, navigationBar.php, and sidebar.php, which indicates a template-based layout boundary.

4. Business logic layer

The controller/ directory is where form submissions and actions are handled. Controllers are split by feature, including authentication (loginController.php, signupController.php, logoutController.php, forgetPassController.php), account management (profileController.php, passwordController.php), ordering (orderController.php), and admin/staff operations (addPizzaController.php, updatePizzaController.php, deletePizzaController.php, addStaffController.php, pizzaAvailabilityController.php, pizzaStatusController.php).

5. Data access layer

The model/ directory encapsulates persistence. connection.php centralizes the MySQL connection, while user.php, pizza.php, and order.php represent the main data domains. This is the main boundary between application logic and the database.

6. Core data domains

The system is organized around users, pizzas, and orders. Users carry roles such as customer, staff, and admin. Pizzas are the catalog/inventory entity. Orders connect customers to purchased pizzas and carry status progression through the workflow.

7. Order and cart flow

Customer shopping is session-driven: browse menu in view/menu.php, add items to view/cart.php, then submit through orderController.php. The controller likely computes totals, creates order records, and writes order items through the model layer. This is the primary transactional path in the system.

8. Operational workflows for staff/admin

Admin and staff use separate operational screens such as dashboard.php, orders.php, availability.php, assigned.php, staff.php, and the pizza management views. pizzaStatusController.php manages order lifecycle updates, while pizzaAvailabilityController.php controls whether menu items are in stock. These are the main back-office control points.

9. Authentication and session boundary

Authentication is handled server-side with PHP sessions. Login/signup/forgot-password flows establish the session identity, and role-based access determines which view/controller set is reachable. This makes session state a key architectural dependency across all modules.

10. Frontend assets

The css/ and js/ directories are organized per screen or feature, so styling and client-side validation are modular but not central to the business architecture. image/ holds static menu assets, while assets/ appears to store documentation screenshots rather than runtime dependencies.

11. Infrastructure and runtime

The stack is traditional PHP 7.4+ on Apache with MySQL 5.7+ access via procedural MySQLi. There is no evidence of an ORM, API backend, or separate service tier; the database is directly accessed through the model classes/functions.

12. Diagram boundaries to emphasize

For an architecture diagram, the important boundaries are: browser/UI views, PHP controller layer, model/database access layer, and MySQL persistence. The key flows are authentication, menu/cart checkout, order-status updates, and admin inventory/staff management. Role-based access sits across all of them.