4. Solution strategy

MRBS uses a modular monolith: one deployable PHP application with internal separation around calendars, authentication, sessions, persistence, forms, internationalisation, mail, and iCalendar.

Strategy summary

Quality goal	Architectural approach
Booking integrity	Central booking checks plus relational persistence and database constraints
Database portability	DBFactory, abstract database behavior, and MySQL/PostgreSQL adapters
Identity flexibility	AuthFactory and SessionFactory with backend-specific classes
Configurability	Layered defaults and site-specific PHP overrides
Deployability	Server-rendered PHP, release-bundled dependencies, no mandatory build step
Localization	Language catalogues, locale abstraction, and timezone-aware formatting
Extensibility	Class families for calendar rendering, forms, auth, session, database, and iCalendar

Request-oriented application

Top-level PHP files are page controllers. Most include defaultincludes.inc, which establishes configuration, infrastructure, identity, language, error handling, upgrades, and standard request variables.

Controllers then coordinate functions and classes and render a complete response.

Factories isolate variants

Three important variability points use factories:

• DBFactory selects MySQL or PostgreSQL behavior.
• AuthFactory selects credential verification.
• SessionFactory selects identity/session acquisition.

Calendar factories select renderers for different views and room combinations.

Relational source of truth

The database stores current entries, recurrence definitions, areas, rooms, participants, local users, schema variables, timezone data, and optionally sessions.

Evolution strategy

Backward-compatibility checks translate or warn about older configuration. Schema upgrade logic evolves installations when a new application version is first run.

This approach reduces manual upgrade steps but makes bootstrap and upgrade paths architecturally sensitive.