
class ReservationService {

  public function calculateTotal()
  {
      return $this->pricingService
          ->applySeasonModifier()
          ->applyDiscountRules()
          ->applyChannelCommission()
          ->applyTaxes()
          ->buildInvoice();
  }

}

// Domain rules evolve
// architecture decisions matter
// complexity grows over time

A01 — Monolithic Eloquent

Direct ORM usage with business logic in models and controllers

Pattern: Active Record / Monolithic

Philosophy: Embrace ORM as the primary abstraction. Fast iteration, minimal boilerplate.

Description

A01 uses Laravel Eloquent models directly in the controller layer. Business logic resides in model methods and controller actions. This approach prioritizes rapid development over long-term maintainability.

Strengths:

Minimal setup; start coding immediately
Leverage Eloquent's expressive query builder
Quick to add simple business logic
No abstraction overhead

Weaknesses:

Tight coupling to the database layer
Logic scattered across models and controllers
Difficult to test without a database
Complexity grows exponentially with domain rules
Hard-coded business rules are brittle

Evolution Across Phases

Phase	Files	Lines of Code	Controller (lines)
Phase 01	6	218	83
Phase 02	6	326	123
Phase 03	6	398	141
Phase 04	7	466	184

Warning: Controller grew 122% (83 → 184 lines). All complexity concentrated in a single method handling 13 distinct responsibilities.

Key Metrics

Total Files

No growth across phases

Total Lines of Code

466

+114% growth P01→P04

Controller Size (Phase 04)

184 lines

+101 lines from Phase 01

Testability Score

Low

Requires database mocking

Conclusion

Simplicity has exponential cost.

A01 is fastest to start but becomes unwieldy as domain complexity grows. The controller handles multiple responsibilities with hard-coded business logic. Early booking discounts are parsed using string manipulation (str_starts_with + explode), creating fragile, difficult-to-maintain code.

By Phase 04, the single controller method has become impossible to test in isolation, and adding new pricing rules requires careful modifications to avoid breaking existing logic.

✓ When to Use A01

Prototype or proof-of-concept with stable, simple logic
Single developer, small team, short project timeline
When you're confident domain complexity will not grow significantly

Back to Comparison View Source on GitHub