Cqrs Laravel Package

Product Decisions This Supports

• Audit trail and compliance features. A CQRS package gives you a structured command log and domain events — the raw material for "who changed what, when, and why" surfaces that show up in enterprise sales questionnaires, SOC 2 prep, and customer support tooling. If audit history is on the roadmap, this is the architectural lever that makes it a byproduct rather than a project.
• Read/write model separation for scale-sensitive screens. Dashboards, search, and reporting can be served from projections while transactional writes stay on normalized tables. This informs whether "make the analytics page fast" is a caching/queue problem or an architecture problem — a decision that usually gets made too late and expensively.
• Event-driven roadmap items. Webhooks, third-party integrations, notification fan-out, and search index sync all become subscribers to domain events instead of ad-hoc hooks scattered through controllers. This is a roadmap-enablement decision: pay once in architecture, then ship integrations faster.
• Build vs. buy for the command/query bus. Every Laravel team eventually hand-rolls a command bus, a job-per-action convention, and a validation pipeline. This package is the "buy" option for that slice — small, MIT, forkable. The real decision is whether to adopt a named pattern with a dependency or keep an internal convention.
• Modular monolith boundaries. Commands and events give product and engineering a shared vocabulary for module contracts, which makes "can we extract this to a service later?" a cheaper question to answer.
• The meta-decision: CQRS or not. The most valuable output of evaluating this package is a documented "we considered event-sourced CQRS and chose X because Y" — that artifact prevents the same debate recurring each planning cycle.

When to Consider This Package

Consider it when:

• The team already speaks DDD/CQRS and needs a thin Laravel-native command/query bus plus event plumbing, not a framework.
• You are comfortable vendoring or forking the code. With 2 stars, 0 dependents, and a single-maintainer footprint, treat it as source code you adopt, not a vendor you depend on.
• The scope is genuinely small: dispatching commands, handling them synchronously or via queue, and publishing domain events. If you need an event store, snapshots, sagas, or projections with replay, verify these exist before committing.
• MIT licensing and a small readable surface area matter more to you than ecosystem support — e.g., you want to audit every line that touches your write model.

Look elsewhere when:

• You need production-grade guarantees: published API stability, security response process, tests you can trust, migration guides. None of that is signaled here.
• Your team is CRUD-oriented and shipping velocity is the priority. CQRS adds indirection; adopting it without the team's buy-in trades delivery speed for theoretical flexibility.
• You need event sourcing with replay, versioning, and projection rebuilds out of the box — evaluate Spatie laravel-event-sourcing, EventSauce, Ecotone, or Prooph instead, all of which have real adoption and documentation.
• You only need async jobs and domain events. Laravel's native events, listeners, and queues cover 80% of that with zero new dependency.
• You require vendor support, SLAs, or a named maintainer to escalate to.

How to Pitch It (Stakeholders)

For executives: This is a small open-source library that would let us record every business action as a first-class event, which turns audit history, activity feeds, and integration hooks from bespoke projects into reusable plumbing. The strategic appeal is speed on a class of enterprise features we keep getting asked for. The risk is maturity: near-zero adoption, no dependents, one maintainer. Recommendation is a time-boxed spike (1–2 weeks), not a production commitment — validate that it does what its name implies, and keep the option to fork it or fall back to Laravel's native events. Low cost to explore, real cost to standardize on.

For engineering: MIT-licensed, small surface, Laravel-idiomatic command/query dispatch and domain events. We'd own the code the moment we adopt it, so budget for reading and forking rather than waiting on upstream. Compare against hand-rolling a bus (a few days) and against Spatie's event-sourcing package (heavier, better supported). If the spike shows the write model and event dispatch are sound, it collapses a chunk of future integration work; if it doesn't, we lose two weeks and gain a documented architecture decision we can reuse.