Weave Code
Use Case Bundle Laravel Package
openclassrooms/use-case-bundle
A Symfony bundle for organizing application logic into explicit use cases. It provides base classes, interfaces, and service wiring to define and execute use cases cleanly, keeping controllers thin and business rules isolated and testable.
openclassrooms/use-case-bundle brings a use case–oriented architecture to Symfony applications. It helps isolate business logic in dedicated, testable services, keeping controllers thin and decoupling application flows from framework code.
- Register and wire use cases through Symfony’s service container.
- Encourage command/input objects for explicit use-case contracts.
- Support reusable application-level concerns such as validation.
- Keep controllers and infrastructure separate from domain logic.
- Make business workflows easier to test and maintain.
Frequently asked questions about Use Case Bundle
- Can I use openclassrooms/use-case-bundle in a Laravel application?
- No. It is a Symfony2 bundle built around registerBundles(), a dependency-injection extension, and compiler passes, and none of that glue executes under Laravel's kernel. The reusable substance sits one layer down in the framework-agnostic openclassrooms/use-case library, which you can wire with your own Laravel service provider.
- What does this bundle add on top of openclassrooms/use-case?
- The bundle is purely framework glue: it registers a DI extension, exposes a configuration tree, and tags or autowires handlers into a message bus via compiler passes. The command, query, handler, and bus abstractions themselves live in the parent library and are plain PHP. That split is why the concept ports to Laravel while the artifact does not.
- How do I use the use-case pattern in a Laravel app?
- Depend on openclassrooms/use-case, or vendor just the interfaces you need, and write a Laravel service provider of roughly 150 lines. That provider should bind the bus as a singleton, tag handler classes, and resolve them from the container through an explicit command-to-handler map. This keeps your dependency graph framework-native and avoids running a second container.
- Which Laravel versions does openclassrooms/use-case-bundle support?
- None are declared, because it is not a Laravel package. Its constraints pin Symfony component ranges and a PHP floor, so installing it under Laravel would couple your Symfony bridge version to your Laravel upgrade cycle. Check its composer.json on Packagist for the exact PHP and Symfony requirements before making any dependency decision.
- Is openclassrooms/use-case-bundle safe to use in production?
- Treat it as an internal OpenClassrooms library published to Packagist: it has 0 stars, 0 dependents, and single-organization ownership, so there is no community backstop or third-party production evidence. Its metadata shows a future-dated 2026-03-04 release, which you should verify against Packagist directly before trusting. MIT licensing means a fork is always available, which materially limits abandonment risk.
- How do I register handlers in Laravel without a Symfony compiler pass?
- Tag handler classes in a service provider and resolve them from the container, either through an explicit command-to-handler map or contextual binding. Read the bundle's compiler pass first, because it encodes the author's handler keying and naming conventions, which is the genuinely non-obvious part. Reimplement that registration contract once in an internal package so multiple services share one implementation.
- How do I test use cases and handlers in Laravel?
- Handlers are plain classes with a single handle method, so you instantiate them directly in unit tests with mocked dependencies and assert the result. Add a thin integration test that dispatches through the bound bus to prove the container resolves the correct handler. Skip testing any Symfony-specific glue, since you will not be shipping it.
- What are the alternatives to this bundle in Laravel?
- Laravel's own command bus covers most of the same ground through Bus::dispatch, synchronous dispatch, and queued dispatch. Packages such as laravel-mediator or League Tactician implement a more explicit mediator if you want stricter CQRS semantics. If you only need handler-resolution plumbing, a small internal provider may be all you need, so check whether your team has already standardized on a dispatch pattern first.
- Does the bundle wrap handlers in transactions or middleware?
- The bundle's visible job is handler discovery and registration; whether it adds transaction wrapping or middleware must be confirmed by reading its DI extension and compiler pass, and the evaluation flags this as an open question. In Laravel you would implement that as bus pipes or a decorating middleware in your own provider. Do not assume you get transactional dispatch for free.
- Should I install the bundle in Laravel via a Symfony container bridge?
- Not recommended. Bridging adds a second container, a second configuration system, and a debugging surface with no payoff at this scale. Install the framework-agnostic core package and write a native Laravel provider instead, and only reconsider the upstream bundle if you genuinely run a Symfony service where it is a drop-in.
Weaver
How can I help you explore Laravel packages today?