Laravel Beyond Laravel Package

Product Decisions This Supports

• Architecture standardization (ADR pattern): The package encodes Action–Domain–Responder conventions as first-class Laravel artifacts. This is the lever for deciding whether the team standardizes on ADR for new service layers, or keeps a conventional MVC/Service-class approach — the scaffolding command (beyond:make:adr-action) makes the pattern cheap enough to trial on one bounded context before committing.
• Build vs. buy for boilerplate: Generating actions, domains, and responders is trivial-but-repetitive work. Adopting the package removes a small internal tooling backlog item; the alternative (a homegrown artisan command set) is only justified if the team's ADR dialect diverges materially from the package's defaults.
• Framework upgrade roadmap: v7.1.0 supports Laravel 12.x and drops Laravel 10.x. This directly constrains the platform upgrade plan — the package now sets a floor of Laravel 11. Any product still on L10 either freezes the package at the last v7.0.x release or accelerates the framework upgrade. Treat this as an input to the L10 end-of-life planning conversation, not a surprise.
• Onboarding and consistency: Prescriptive structure lowers the cost of bringing new engineers into a codebase and reduces reviewer bikeshedding on "where does this logic live." Useful signal when scoping hiring or contractor onboarding for a growing team.
• Feature delivery predictability: A consistent action/responder boundary makes vertical slices easier to estimate and parallelize across squads — relevant when planning capacity for multi-team roadmaps.

When to Consider This Package

Consider it when:

• The team is on Laravel 11 or 12 (v7.1.0 no longer supports Laravel 10).
• You have — or expect — a codebase large enough that "where does business logic go?" is a recurring, costly debate.
• You want a low-ceremony, opinionated structure without adopting a full DDD framework (no aggregates, no event sourcing, no heavy abstractions).
• You're standardizing architecture across multiple squads or services and want a shared vocabulary.
• You want scaffolding to make the pattern the path of least resistance rather than a documented convention people ignore.

Look elsewhere when:

• You are pinned to Laravel 10 and cannot upgrade in the near term — either stay on the previous v7.0.x line with a known shelf life, or pick an alternative.
• The product is a small CRUD app or MVP where a single controller and a model are genuinely sufficient; ADR adds indirection that will read as ceremony.
• Your team already runs a mature, homegrown architecture (modular monolith, hexagonal, CQRS) with its own conventions — introducing a second vocabulary creates friction.
• You need heavy domain modeling (aggregates, invariants, domain events) — this package is a structural convention, not a domain-modeling toolkit.
• You are evaluating a one-off script or internal admin surface where the pattern's benefits never accrue.

How to Pitch It (Stakeholders)

To executives: This is a low-cost, low-risk structural convention for our Laravel codebase. It gives us a repeatable shape for business logic and a one-line command to scaffold it, which shortens onboarding and makes estimates more predictable across squads. Adoption cost is measured in days, not quarters, and it's reversible — it's a convention, not a platform. The one decision it forces is timing: the current release targets Laravel 11–12 and no longer supports Laravel 10, so it should be sequenced with our framework upgrade rather than before it.

To engineering: Adopt v7.1.0 if we're on Laravel 11+. It adds beyond:make:adr-action for scaffolding actions and brings Laravel 12 support. Note the breaking change: Laravel 10 support is removed — services still on L10 will pin to v7.0.x and miss future fixes; factor that into the upgrade plan. The pattern is intentionally lightweight: one action, one domain, one responder, no framework lock-in at runtime, so we can back out per-service if it doesn't earn its keep. Suggested approach: pilot on one bounded context, measure review friction and time-to-first-PR for new joiners, then decide on org-wide default.