class ReservationService {

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

}

// Domain rules evolve
// architecture decisions matter
// complexity grows over time
Back to Comparison

A04 — Decorator Domain

Compose behaviors dynamically through decorators without modification

Pattern: Builder + Decorator Pattern

Philosophy: Open/Closed Principle. Add behavior through composition, never modification.

Description

A04 applies the Decorator Pattern with a Builder to compose pricing rules dynamically. Each pricing rule (discount, tax, surcharge) is a separate decorator wrapping the previous one. New rules require new decorator files, not modification of existing code.

Strengths:

  • Open/Closed Principle: extend through composition, not modification
  • Each decorator is a single responsibility: apply one rule
  • Pure domain logic, highly testable without database
  • Scales horizontally: new rules = new files, existing code untouched
  • Phase 05 would barely require changes to existing code
  • Chainable rules allow complex pricing scenarios

Weaknesses:

  • Highest initial cost (22 files, 1139 lines in Phase 04)
  • Steep learning curve for decorator composition concept
  • Debugging can be complex: decorators are wrapped inside each other
  • Builder configuration must be precise to get correct rule order
  • Over-engineering for simple, stable domains

Evolution Across Phases

Phase Files Lines of Code Controller (lines)
Phase 01 13 423 32
Phase 02 16 671 32
Phase 03 19 878 32
Phase 04 22 1139 32

Horizontal Scalability: Controller never changes (32 lines). New files added (+9) but existing code untouched. Each decorator is a focused, testable unit. Higher initial cost pays dividends as domain evolves.

Key Metrics

Total Files (Phase 04)

22

+9 files, all new decorators

Total Lines of Code

1139

+169% growth P01→P04

Controller Size (All Phases)

32 lines

Zero growth across all phases

Testability Score

Excellent

Pure domain, no DB needed

Conclusion

Horizontal scalability at a cost.

A04 is the most sophisticated approach. It delivers on the promise of the Open/Closed Principle: the system grows through new files, not modifications. Each decorator is focused, testable, and independent. Phase 05 would add a few new decorators without touching existing code.

The trade-off is significant upfront complexity: 22 files and 1139 lines for Phase 04. This investment is justified when rules change frequently, but overkill for stable domains. This is the pattern to reach for when you know your domain will evolve rapidly and needs protection against fragility.

✓ When to Use A04

  • Pricing rules change frequently and unpredictably
  • Business expects long-term maintenance and evolution
  • Team has experience with design patterns and composition
  • Each rule should be independently testable and deployable
  • You need zero-modification extensibility
Back to Comparison View Source on GitHub