Architecture

Architecture

Current Architecture Summary

The current motmaina-website application is a PHP monolith built on top of CodeIgniter with an HMVC-style modular extension.

At runtime, the application is bootstrapped through a single front controller, then dispatched into module-specific controllers based on routing rules.

Entry Point and Runtime

The application starts from motmaina-website/index.php, which does the following:

• loads environment variables through application/helpers/env_helper.php
• loads Composer autoloading
• sets the current application environment from CI_ENV
• boots the CodeIgniter application using the system/ and application/ directories

This means the website follows the classic server-rendered PHP request lifecycle rather than a client-heavy SPA architecture.

Framework Pattern

The codebase uses:

• CodeIgniter as the base framework
• MX_Controller from application/third_party/MX for modular HMVC behavior
• MY_Controller as the shared base controller in motmaina-website/application/core/MY_Controller.php

MY_Controller extends MX_Controller and centralizes common controller bootstrapping such as session loading. This indicates a shared inheritance model for all higher-level modules and controllers.

Application Layers

The codebase is organized using the standard CodeIgniter folder layout plus module-specific domains:

• application/config for global configuration and root routing
• application/core for framework extensions such as MY_Controller
• application/helpers for shared procedural helpers
• application/libraries for reusable service-style classes, including payments, PDF generation, QR code handling, and mailing
• application/models for shared data access models
• application/views for shared views and error templates
• application/modules for domain-specific HMVC modules

This is not a strict clean architecture split. Instead, it is a pragmatic layered monolith where controllers, models, views, libraries, and helpers are grouped by module and by shared framework conventions.

Module Structure

The main feature areas are separated into modules under application/modules:

• site for the public website
• customer for authenticated customer-facing flows
• api for mobile or external API endpoints
• acp for the admin control panel

Each module contains its own:

• config
• controllers
• models
• views

This confirms a modular HMVC organization where each bounded area owns its route definitions and MVC assets.

Routing Model

Global routing is defined in motmaina-website/application/config/routes.php.

The root routing file:

• sets site as the default controller
• defines top-level shortcuts such as login, cu, acp, and api
• loads additional route files dynamically from each module under application/modules/*/config/routes.php

This produces a two-level routing model:

1. root routes for global entry points and shared shortcuts
2. module routes for detailed feature routing

Public Website Module

The site module contains the public website experience and is the main web-facing module.

Its route file shows that it handles:

• informational pages such as aboutus, terms, and contactus
• content sections such as news, blogs, and forum
• service and team pages
• appointments and consultation entry flows
• courses, trainers, collections, and carts
• webhook and cron-style endpoints

This means the public website is not isolated as a thin presentation layer. It already contains a large amount of product behavior and route orchestration.

Customer, API, and Admin Areas

The current architecture also separates other traffic types into dedicated modules:

• customer handles login, registration, verification, password reset, membership, and authenticated customer paths under cu/*
• api exposes grouped API controllers such as Auth, Customer, Store, Subscription, Diet, and others
• acp provides the admin control panel and authentication routes

In practice, the project behaves as one deployable application with multiple delivery surfaces inside the same codebase.

Shared Integrations and Utilities

The monolith includes internal libraries and third-party packages for operational concerns, including:

• payment gateways such as Hyperpay and Tabby
• PDF generation and invoice printing
• Google API integration
• PHPMailer
• QR code generation
• Sentry through Composer

These integrations are mostly wired into reusable libraries under application/libraries and application/third_party, which is typical for a mature CodeIgniter monolith that grew around business workflows.

Architectural Implications

The current architecture has several clear characteristics:

• server-rendered PHP application
• modular HMVC structure
• one shared deployment unit
• route-heavy controllers with module-based separation
• shared libraries and helpers for cross-cutting business logic

This architecture is effective for incremental feature delivery, but it also means product logic, routing, integrations, and rendering are closely coupled inside the same application boundary.

Recommended Documentation Framing

For documentation purposes, the architecture should be described as:

• a modular CodeIgniter monolith
• organized by delivery surface: public site, customer area, API, and admin
• extended with HMVC modules using MX_Controller
• supported by shared helpers, libraries, and framework overrides

This framing matches the current implementation more accurately than describing the website as a standalone frontend or a microservice-based system.