Why no decorators in domain/application code?
Domain behavior should describe business rules, not container mechanics. Keeping classes plain TypeScript makes them easier to test, port, and reason about in isolation.
Philosophy
Architecture survives longer than frameworks
Decorator-heavy models can feel productive early, but they quietly couple business code to infrastructure choices. We prefer boundaries that still make sense years later.
Why external wiring?
Wiring is composition policy. Policy changes over time, often faster than business language. External config allows this policy to evolve without touching your domain model.
The long-term payoff
Lower coupling reduces rewrite pressure. Teams can replace transport layers, persistence adapters, and deployment targets while preserving core use cases.