Backend Contracts module
Defines backend-facing interfaces and persistence contracts.
Port definitions
CustomerFieldRepository.php, CustomerIdentityProvider.php and VenueRepository.php define what the business layer needs to know without committing it to a specific WordPress table or login cookie. An implementation may later migrate away from WordPress if it still satisfies the same contracts. These interfaces should contain domain concepts such as stable HSLG customer identifiers, field records and venues.
Security implications
Do not accept an arbitrary customer UUID from client data as proof of access. Identity comes from an authenticated provider. Field repositories must preserve original write metadata and enforce the approved latest-selection rule, while order or session repositories have different transaction semantics. Interface changes require repository tests and a review of current WordPress adapters.
Compatibility review
Before changing an interface, enumerate every implementation and caller. Tests must reject invalid identities and preserve the agreed MariaDB timestamp semantics even when a mock supplies values. A new external service should be fitted behind one focused port instead of added directly to shared UI screens.
Source files in this module
- backend/contracts/CustomerFieldRepository.php
- backend/contracts/CustomerIdentityProvider.php
- backend/contracts/VenueRepository.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.