Laravel Decorator Laravel Package

Product Decisions This Supports

• Cross-cutting concern rollout without a rewrite. Decorators let you bolt caching, logging, metrics, authorization, retries, or tenant scoping onto existing service methods instead of editing every class. This is the primary roadmap decision it unlocks: instrumenting legacy/domain code incrementally rather than scheduling a refactor.
• Build vs. buy for an interceptor layer. Rather than designing an in-house pipeline/attribute-resolver, this package provides the primitive (register decorators per Class@method, invoke via a single call site). Relevant if your backlog contains "add observability/authz to N services" and you're weighing a platform-level solution against a small dependency.
• Where to draw the middleware boundary. Laravel middleware covers HTTP; this covers domain/service calls. That distinction drives architecture decisions about what belongs in HTTP middleware vs. business-layer decoration (e.g., rate-limiting an internal pricing method, not a route).
• Experiment and toggle strategy. Decorators are a clean seam for A/B tests, feature flags, or swapping pricing/eligibility strategies per environment without branching inside the method itself.
• Scoping honesty: this is not transparent AOP. Callers must route through Decorator::call(...), so the decision is really "do we adopt a decorated-call convention for these services?" — which has a design/code-review cost, not just an install cost.

When to Consider This Package

Consider it when:

• You have a bounded set of service classes with repeated cross-cutting logic and want to avoid editing each one.
• The concern is at the domain layer, not the HTTP layer (where normal middleware is the right answer).
• You're comfortable with a small, single-maintainer dependency and can vendor or fork it — the codebase is tiny and MIT-licensed, which materially lowers the risk.
• You want a lightweight, dependency-free primitive (no container gymnastics, no proxy generation, no runtime class rewriting).

Look elsewhere when:

• You need transparent interception of existing calls — use the container's decorator/extend pattern, a proper AOP package, or explicit strategy injection instead.
• The concern is request-scoped HTTP: Laravel middleware already does this better and with more team familiarity.
• Your org has dependency governance requiring active maintenance, multiple maintainers, or meaningful dependent counts (139 stars, 0 dependents, last release April 2024 — signals a niche, low-adoption library).
• Static analysis, IDE "find usages," and refactor-safety are non-negotiable: string-based Class@method registration is a discoverability footgun.
• You're on an older PHP/Laravel version — verify compatibility rather than assuming.

How to Pitch It (Stakeholders)

Executives: A small, free (MIT), single-purpose library that lets us add logging, caching, and access checks to existing business logic without rewriting it. Upside is faster delivery on observability/compliance items; downside is limited maintenance exposure from a low-adoption package. Recommended posture: pilot on one or two services, keep it vendored so we're never blocked, and don't make it load-bearing for anything critical.

Engineering: Lightweight decorator primitive for service-method calls — register decorators against Class@method and dispatch through the package's call site. It's not transparent AOP: adoption means a convention that decorated calls go through the facade, which we should document and lint. It complements, not replaces, HTTP middleware. The package is small enough to audit in an afternoon and fork if the maintainer goes quiet; the decision to make is whether the convention cost is worth removing duplication across our service layer.