Verbs Commands Laravel Package

Product Decisions This Supports

• Architecture: command bus / CQRS adoption. This package exists to give a Laravel app a conventional home for "commands" (intent objects) and their handlers, sitting on top of hirethunk/verbs (an event-sourcing package). The decision it informs is whether to introduce a command layer between HTTP/queue entry points and your domain model — and whether to do it with an established, opinionated convention rather than hand-rolling one.
• Build vs. buy for domain plumbing. The realistic alternative is writing command dispatch, handler resolution, and validation glue in-house (typically ~a few hundred lines that slowly rot). This package is the "buy" option — but see the caveats below, because "buy" here means "adopt lightly-maintained MIT code," not "sign a contract."
• Feature selection for audit-critical domains. Event sourcing + explicit commands pays off where you need a durable record of why state changed: financial ledgers, order/shipment state machines, approval workflows, entitlement changes, inventory movements. If your roadmap has any of these in the next 2–3 quarters, this is the moment to standardise; retrofitting command semantics onto CRUD is expensive.
• Roadmap sequencing and scope. Adopting this implies committing to an ecosystem (Verbs) with its own conventions for aggregates, projectors, and reactors. That is a multi-sprint architectural commitment, not a drop-in utility — so it belongs in a technical-roadmap conversation, not a backlog ticket.
• Team conventions as a product asset. Command/handler naming and placement reduces onboarding cost and makes domain logic greppable. Worth valuing explicitly if you have multiple squads touching the same bounded context.

Verification required before committing: confirm with engineering exactly what surface this package adds on top of verbs (handler auto-resolution? command generation? validation pipeline?), and whether it is load-bearing or optional convenience. I would not commit roadmap items to it until a spike confirms that.

When to Consider This Package

Consider it when all of the following hold:

• You are already committed to, or actively piloting, hirethunk/verbs (or are prepared to adopt it as part of the same decision). This package is an adjunct, not a standalone product — it is not a general-purpose command bus and does not replace laravel/framework's bus or spatie/laravel-event-sourcing.
• Your domain genuinely benefits from event sourcing (auditability, temporal queries, replay, multiple read models) rather than merely wanting tidier controllers.
• Your team is comfortable with DDD-adjacent patterns and can own the code: pin the version, vendor or fork it, and treat it as internal infrastructure.
• The blast radius is bounded — a single bounded context or a new service — so a low-adoption dependency cannot stall a revenue-critical path.

Look elsewhere when:

• You just need cleaner controllers. Laravel Actions, single-action invokable controllers, or plain jobs give you 80% of the benefit at zero dependency risk.
• You need the ecosystem without the single-package risk. spatie/laravel-event-sourcing (large community, active maintenance) or ecotone are the mainstream alternatives; pick based on team familiarity, not features.
• You need vendor support, SLAs, or a security-response commitment. Not available here.
• The signals are a problem for your governance model. One star, zero dependents, last release June 2024, and a low composite score mean effectively no external production validation. In a regulated or long-lived codebase, the maintenance burden is yours alone — the MIT license is permission, not a promise.
• Your workload is high-throughput CRUD. Event sourcing and command buses add operational surface (event store, projections, eventual consistency, replay tooling) that you will pay for every day.

How to Pitch It (Stakeholders)

One line: A small, MIT-licensed Laravel add-on that gives event-sourced applications a disciplined command layer — high leverage if we're already going event-sourced, near-zero value otherwise.

To executives: This is not a product; it's a construction material. It costs nothing to license, but the real cost is the architectural commitment it implies and the ownership we take on by adopting thinly-validated open source. Recommendation: do not fund it as an initiative. Approve it only as part of a bounded pilot in one domain where audit trail and state-history requirements are already on the roadmap — and require the pilot to demonstrate that the verbs ecosystem earns its operational overhead before we standardise.

To engineering: Strong conceptual fit for CQRS/event-sourcing work in Laravel and useful for enforcing command/handler conventions, but treat it as a fork candidate from day one — pin the version, keep an internal copy, and expect to maintain it. Low adoption (1 star, 0 dependents, single 2024 release) means no upstream safety net and no community answers when something breaks. Validate the integration in a one-week spike with a real aggregate before it touches a critical path.

Decision requested: Approve a time-boxed spike (1 engineer, ~1 week) in one bounded context; defer any broader adoption decision until the spike reports on ergonomics, maintenance burden, and whether verbs itself is worth the operational cost.