Symfony Adr Laravel Package

Product Decisions This Supports

• Architecture standardisation (ADR vs. default MVC). The package operationalises the Action–Domain–Responder pattern inside Symfony's DI container: one invokable Action per endpoint, a Domain layer free of HTTP concerns, and a Responder that owns output formatting. Adopting it is a convention decision as much as a technical one — it determines folder contracts, code review expectations, and onboarding material for every HTTP-facing team.
• Build vs. buy. ADR is a ~200-line pattern; a competent team can hand-roll the wiring in a sprint. Buying the package buys convention, maintained container integration, and — as of v1.4.0 — a maintained compatibility claim against Symfony 6. That is a maintenance-cost trade, not a capability trade.
• Roadmap alignment with the framework upgrade. v1.4.0 adds Symfony 6 support and nothing else. Its value is entirely contingent on whether a Symfony 6 migration is already on the roadmap. If it is, this release unblocks or de-risks that workstream. If the estate is on 5.4 LTS with no upgrade funded, the release changes nothing and should not generate its own initiative.
• Use cases to green-light. API-first services, teams with chronically fat controllers, and strangler-style migrations where individual endpoints can be lifted into Actions one at a time without a rewrite. The per-action DI model makes incremental adoption genuinely low-risk.
• Vendor-risk posture. This is a small, single-maintainer package with an irregular cadence (v1.3.1 → v1.4.0 spans roughly six months for a framework-compatibility bump). Capability additions are infrequent. Plan for the pattern, not for the maintainer: wrap the base classes behind an internal abstraction so an abandonment is a two-day substitution rather than a rewrite.
• Applicability note for a Laravel-leaning portfolio. The ADR pattern transfers cleanly to Laravel; this package does not — it is Symfony-kernel-specific. Treat it as a reference implementation for Laravel teams and a direct dependency only for Symfony services. Do not let the pattern's value be mistaken for a reason to introduce a second framework.

When to Consider This Package

Adopt when:

• The service runs on, or is funded to migrate to, Symfony 6 — the only substantive change in this release, and the gating criterion.
• You want ADR conventions without owning the DI plumbing, and the team is small enough that a shared external convention beats a bespoke internal one.
• You need per-action services with isolated request handling, primarily for testability of endpoint logic without booting a full HTTP kernel.
• Multiple teams need an identical action contract, where the package's enforced structure is worth more than the freedom to design your own.

Look elsewhere when:

• The estate is Laravel-first. No Symfony kernel, no fit — take the pattern, not the dependency.
• The service is pinned to Symfony 5.x or below with no upgrade path funded; adoption buys an immediate constraint you cannot satisfy.
• You need vendor-backed support, an SLA, or security-response guarantees. There are none here.
• Your domain logic is dominated by form/validation/ORM conventions where the framework's own controller and binder tooling already carries the weight; ADR adds indirection without removing work.
• You already have a working, reviewed controller convention. Re-platforming for naming purity is not a business case.
• You require a guarantee of forward compatibility with Symfony 7. None has been made.

On this specific release: v1.4.0 is a compatibility bump, not a feature release. It carries no breaking changes and no deprecations. It warrants action only where Symfony 6 is already in scope; otherwise note it and move on.

How to Pitch It (Stakeholders)

For executives (one paragraph): This is a low-cost architectural hygiene decision, not a platform bet. The package enforces a clean separation between request handling, business logic, and response formatting — the practical effect is smaller, more testable units of code and fewer defects that only surface at the HTTP boundary. Licence cost is zero, integration surface is deliberately thin, and the pattern is portable: if the package is ever abandoned, we keep the architecture and replace roughly a day of wiring. The v1.4.0 release adds Symfony 6 support, which matters only because it aligns with an upgrade already on our roadmap — it makes that migration slightly cheaper and does not create new work. The honest caveats are that it is maintained by a single author with no support contract, and that it applies to our Symfony services only, not our Laravel ones. Recommendation: adopt within Symfony services where a Symfony 6 upgrade is already funded, pin the version, isolate behind an internal abstraction, and revisit the dependency annually.

For engineering leads (talking points):

• Thin invokable Actions, explicit DI per endpoint, no service-locator magic — the code reads as the request flow.
• Domain layer carries no HTTP types; Responders own serialisation, so output format changes stop touching business logic.
• Testability is the headline benefit: Actions are plain services and can be exercised without a kernel boot.
• Adopt incrementally — one endpoint per sprint. No rewrite required, no framework-wide commitment.
• Mitigations: pin to v1.4.x, wrap Action/Responder base classes in our own namespace, and keep a written note that the pattern is ours and the package is an implementation detail. That converts single-maintainer risk into a routine substitution.
• Do not port the dependency into Laravel services; port the pattern if the teams want it.