🔄 Refactor: Remove Business Logic from Controllers & Introduce DTO-Oriented Services

[MrAdder]

Refs #4550

🎯 Purpose of this PR

This refactor removes business logic from controllers and reorganises data handling through service-layer DTO-style structures.

Primary goals:

• Keep controllers thin and focused on HTTP concerns
• Move domain/business logic into dedicated services
• Centralise response/data shaping logic
• Improve long-term maintainability and testability

There are no intended functional changes.

---

🧱 What Changed

✅ Business Logic Extraction

Controllers previously responsible for:

• Validation decisions
• Data shaping
• Query logic
• Eligibility calculations
• Response construction

Now delegate to services which return structured data objects.

---

🧩 DTO-Oriented Structure

Service methods now:

• Build structured payloads internally
• Standardise returned data formats
• Reduce controller responsibility for assembling arrays/responses

This lays groundwork for formal DTO adoption later.

---

🗂️ Services Introduced / Expanded

• CtsBookingsService
• OAuthUserProfileService
• PositionValidationService
• HeathrowGroundS1EligibilityService
• PasswordManagementService
• ForgotPasswordFlowService
• LocalBanDisplayService

---

🔍 Reviewer Focus Areas

1. Behavioural Parity

Because logic moved layers, please verify:

• Same responses returned
• Same status codes
• Same validation outcomes

Assume differences are accidental unless stated otherwise.

---

2. DTO / Response Construction

Main architectural change:

• Controllers no longer build large arrays
• Services now prepare response-ready data

Check for:

• Missing keys
• Renamed fields
• Null handling differences

---

3. High-Risk Functional Areas

CTS Bookings API

• Rate limiting logic moved
• Header handling now service-driven

OAuth Profile Endpoint

• Full response shaping extracted

Heathrow Ground S1 Eligibility

• All eligibility rules moved into service

Password & Reset Flow

• Mutation logic removed from controllers

Position Validation

• Lookup + caching extracted

---

🚫 Not Intended to Change

• Routes
• Permissions
• API schemas
• Validation rules
• Auth behaviour

---

🧭 Architectural Context

This PR is part of an ongoing effort to:

• Eliminate business logic from controllers
• Move toward DTO-driven service responses
• Enable cleaner unit testing boundaries

Future follow-ups may introduce:

• Explicit DTO classes
• Standardised service response contracts

---

✅ Reviewer Checklist

• Confirm controllers only orchestrate
• Validate DTO payload structure remains identical
• Check exception handling parity
• Watch for query or eager-load regressions
• Verify auth context propagation (auth()->id())

---

Thanks for reviewing — this is a structural change touching multiple domains, so regression-focused feedback is especially helpful 👍

[MrAdder]

This will need testing fully I have tested locally everything that I can think of and pages, updated tests to reflect changes if required for changes in business logic

[MrAdder]

This I am converting to draft till others are merged just incase of conflicts