Backend Services module
Implements business operations with domain-specific idempotency, authentication and payment rules.
Business-layer responsibilities
CustomerProfileReader.php reads approved customer-field values through a repository. OrderLifecycle.php defines conservative order transitions and unknown outcomes. ServerPricedBasket.php keeps price authority on the server, while VerifiedStripeReceipt.php represents provider evidence rather than arbitrary client claims. ListVenues.php serves venue information through its own repository interface.
Why operations stay separate
Customer profile state, order state, catalogue prices and payment settlement have different consistency rules. Combining them into one all-purpose database helper invites mistakes such as treating newest customer-field data as a paid order. Service classes should validate inputs and domain state, then call an authorized repository or provider. Client-rendered totals or QR scans do not establish account ownership or financial acceptance.
Testing responsibility
Exercise allowed/forbidden transitions, duplicates, missing identity, changed product prices and unverified payment evidence. A server-side unit test may establish the logic's shape but cannot replace real MariaDB and Stripe staging verification.
Source files in this module
- backend/services/accounts/CustomerProfileReader.php
- backend/services/orders/OrderLifecycle.php
- backend/services/payments/ServerPricedBasket.php
- backend/services/payments/VerifiedStripeReceipt.php
- backend/services/venues/ListVenues.php
Maintenance and evidence
Check all affected file references and the matching human-readable user/architecture page when source changes. Run the module’s contract or governance checks; staging, payment and native hardware tests remain independent of source inventory coverage.