Weave Code
Cqrs Laravel Package
artisansdk/cqrs
ArtisanSDK CQRS provides command and query buses for Laravel, routing commands and queries to handlers via the container. It supports middleware and clean separation of write/read concerns, helping build maintainable, testable applications.
A foundational package for Command Query Responsibility Segregation (CQRS) compatible with Laravel.
Frequently asked questions about Cqrs
- How do I install artisansdk/cqrs in a Laravel application?
- Install it with composer require artisansdk/cqrs; Laravel package auto-discovery should register the service provider and facades. Publish any configuration only if the package docs require it, then validate the developer experience with one command, one handler, and one query. The spike cost should be hours, not weeks.
- What Laravel and PHP versions does artisansdk/cqrs support?
- The provided context does not state an exact Laravel or PHP version range, so verify the current release's composer.json and README before adoption. Because the package depends on Laravel container resolution, service provider registration, and facade behavior, treat support for your target Laravel major as an explicit upgrade gate.
- Does artisansdk/cqrs support middleware for commands and queries?
- Yes. The package supports middleware around command and query buses, which is where you should put cross-cutting concerns such as transactions, logging, authorization, or idempotency. The overview does not enumerate built-in middleware, so plan to implement and document the middleware your application needs.
- Can artisansdk/cqrs dispatch commands asynchronously on a Laravel queue?
- The package is not described as providing a transport or queue integration, so do not assume built-in async command dispatch. You can layer asynchronous behavior with Laravel queue jobs that invoke the bus or handler, but you own serialization, retries, idempotency, and failure handling.
- Is artisansdk/cqrs a full event sourcing or CQRS framework?
- No. It is a thin CQRS enabler: command and query buses, container-based handler resolution, contracts, traits, and middleware. It does not ship event sourcing, read-model projections, aggregate persistence, sagas, or event replay, so those architecture pieces remain your responsibility.
- How should I test commands and queries with artisansdk/cqrs?
- There are no dedicated fakes or bus assertion helpers described in the provided context, so rely on Laravel's container and testing conventions. Swap in fake handlers or a fake bus through the container, test handlers directly, and add integration tests for routing and middleware. Keep command and query payloads deterministic so tests stay simple.
- What are good use cases for artisansdk/cqrs in an existing Laravel app?
- Use it when your team has already chosen a light command-bus discipline and wants Laravel-native glue without a heavyweight framework. The query side is the lowest-risk starting point because it is read-only and easy to compare with existing code paths. Commands work well for write use cases once you define conventions for validation, transactions, and authorization.
- How do I structure handlers and DTOs with artisansdk/cqrs?
- The package deliberately imposes no directory layout or persistence model, so your team must define handler naming, DTO versus array payloads, validation placement, transaction boundaries, and authorization ownership. Document those conventions and enforce them in code review, or the bus will become a second parallel way to call services.
- What are alternatives to artisansdk/cqrs for CQRS in Laravel?
- Alternatives mentioned in the evaluation include Symfony Messenger, Ecotone, and Prooph, which are heavier frameworks with more built-in architecture. ArtisanSDK CQRS is a better fit when you want Laravel-native buses and are willing to design the rest yourself. Compare them on async transport, projections, and event sourcing if those are requirements.
- Is artisansdk/cqrs maintained and safe for production?
- The main risk is sustainability: the package has a small star count and single-maintainer profile, though it is thin enough to fork or vendor with a pre-agreed contingency budget. Runtime blast radius is low because it requires no migrations, queues, or external services; worst case is usually a contained handler-resolution exception. Put a named internal owner in place and gate Laravel upgrades on package compatibility.
Weaver
How can I help you explore Laravel packages today?