9. Architecture decisions¶
These records describe decisions visible in MRBS 1.12.2. They document the current architecture; they are not reconstructed meeting minutes.
ADR-001: Server-rendered modular monolith¶
Status: Implemented
Decision: Deliver MRBS as one PHP application composed of page controllers, shared functions, and internal class families.
Rationale: Straightforward deployment on conventional PHP hosting and direct access to a transactional relational database.
Consequences: Deployment is simple, but page, bootstrap, and shared global state can be tightly coupled.
ADR-002: Support MySQL-family and PostgreSQL databases¶
Status: Implemented
Decision: Keep a common database abstraction with database-specific adapters and schema scripts.
Rationale: Existing installations use both ecosystems.
Consequences: New persistence behavior must be implemented and tested on both variants.
ADR-003: Separate session acquisition from authentication¶
Status: Implemented
Decision: Select session and authentication adapters independently through factories.
Rationale: HTTP, PHP, SAML, CAS, CMS, cookie, and other identity flows obtain and retain identity differently from credential verification.
Consequences: The configuration is flexible but exposes combinations that must be validated and documented.
ADR-004: Use layered PHP configuration¶
Status: Implemented
Decision: Express defaults and overrides as PHP variables and arrays.
Rationale: It works without a configuration parser and supports computed or conditional settings.
Consequences: Configuration is powerful and backward compatible, but not declarative, typed, or safely editable through generic tools.
ADR-005: Store area policy in the database¶
Status: Implemented
Decision: Use areadefaults.inc.php only to initialize new areas; persist
active area settings in the database.
Rationale: Administrators can configure each area in the browser.
Consequences: Changing the defaults does not affect existing areas and can surprise operators.
ADR-006: Bundle production dependencies¶
Status: Implemented
Decision: Ship required third-party PHP libraries inside web/lib.
Rationale: Release installation does not require Composer or shell access.
Consequences: Dependency updates and vulnerability tracking are repository maintenance tasks, and bundled legacy code can constrain PHP compatibility.
ADR-007: Run schema upgrades from the application¶
Status: Implemented
Decision: Detect and execute required database upgrades during application startup.
Rationale: Operators do not have to run every historical migration manually.
Consequences: Upgrade behavior is part of the request bootstrap and may temporarily require elevated database credentials.