Service Bus Laravel Package

Product Decisions This Supports

• Architecture direction: Whether to make CQRS and explicit command/query separation part of the product’s technical strategy, especially for a modular monolith or domain-heavy Laravel application.
• Feature delivery model: Whether write operations should be modeled as commands (single handler, explicit intent) and reads as queries, improving traceability and reducing controller/domain coupling.
• Build vs. buy vs. wrap: Whether to adopt a lightweight message bus instead of building an internal dispatcher or using Laravel’s native bus/queue and Symfony Messenger. This package is best treated as a tactical component behind an internal interface, not as a platform commitment.
• Cross-cutting concerns: Whether validation, authorization, transactions, logging, metrics, and audit trails should be enforced consistently through bus middleware rather than repeated in controllers or services.
• Roadmap sequencing: Whether to start synchronous and later move selected commands to queues/async workers without rewriting handlers, supporting incremental modernization.
• Team boundaries: Whether to standardize handler contracts and message objects across modules, making ownership and bounded contexts clearer.
• Dependency risk: Whether the product can accept a niche package with 441 stars and a last release in August 2021, including a plan to verify PHP/Laravel compatibility and own maintenance if adopted.

When to Consider This Package

Consider it when:

• The team has a concrete CQRS or command-bus requirement, not just a vague desire for “clean architecture.”
• You need a small, framework-agnostic message bus with command/query handling and middleware, and the team can own Laravel integration wiring.
• You are already in or evaluating the prooph ecosystem, or you need a lightweight bus without adopting a full framework.
• BSD-3-Clause licensing is acceptable and legal/security review confirms it fits distribution or SaaS use.
• Engineering has verified compatibility with the target PHP and Laravel versions, including dependency constraints and test coverage.
• You can isolate it behind an internal CommandBus/QueryBus adapter so replacement is feasible.

Look elsewhere when:

• You are building a greenfield Laravel app without a specific CQRS need; Laravel’s native dispatcher, events, queues, and Horizon cover most use cases.
• You require active maintenance, frequent releases, modern PHP/Laravel support, or vendor-backed security response.
• You need first-class async transports, retries, dead-letter queues, scheduling, failure handling, and observability out of the box; Symfony Messenger or Laravel queues are stronger defaults.
• The team lacks appetite for custom service-provider wiring, handler registration, serialization decisions, and long-term dependency ownership.
• CQRS would add complexity without a product or scale justification.

How to Pitch It (Stakeholders)

Executive summary: This is a lightweight, permissively licensed PHP message bus that can support CQRS-style separation of writes and reads. It is not an end-user feature; it is an architectural enabler for clearer domain boundaries, consistent middleware, and incremental async processing. The main concern is maturity: low star count and a 2021 last release mean adoption should be a time-boxed pilot behind an internal abstraction, not an unfunded platform bet.

Engineering summary: Prooph Service Bus provides commands, queries, handlers, and middleware. In Laravel, it would require integration work around service providers, handler resolution, and dispatch conventions. Start synchronous, prove the middleware and handler model, then evaluate queue-backed execution. Compare explicitly against Laravel’s native bus/queue and Symfony Messenger; choose this only if its CQRS/middleware model materially reduces custom code or fits an existing prooph footprint.

Product recommendation: Fund a short spike only if the roadmap includes modular-monolith boundaries, auditable command handling, or CQRS. Gate adoption on PHP/Laravel compatibility, maintenance ownership, and a replacement path. Otherwise, default to Laravel-native messaging and revisit this package only for narrow, well-understood use cases.