- What does nicolasjourdan/business-logic-bundle actually do?
- It is a Laravel code-generation package that adds Artisan maker commands for organizing business logic into dedicated, reusable classes. Release 1.1.0 introduces MakeSpecification and MakeRule, which scaffold Specification pattern classes and explicit business rule classes. The goal is to move domain rules and workflows out of controllers and keep services lean. It runs at development time only, not in your application's runtime path.
- How do I install business-logic-bundle in a Laravel application?
- Install it with Composer as a dev-time dependency, for example composer require nicolasjourdan/business-logic-bundle. Laravel package auto-discovery should register the service provider so the new make commands appear in php artisan list without manual wiring. If auto-discovery is disabled in your app, register the provider manually in the providers configuration. Always confirm the exact namespace and command names against the repository before scripting them into CI.
- Which Laravel and PHP versions does this package support?
- That detail is not stated in the overview, so check the composer.json require block and the Packagist release history before adopting it. Expect it to target modern PHP 8+ and a recent Laravel range, but verify rather than assume, especially if you are on Laravel 9, 10 or 11. If your project is pinned to an older framework version, test installation in a sandbox branch first.
- Does this package affect application runtime performance?
- No. The package is an Artisan-based scaffolding tool, so its commands execute during development and produce ordinary PHP classes that become part of your codebase. There is no runtime service provider overhead beyond registration, and generated classes carry no framework coupling by default. Any performance impact comes only from how you design and call the generated specifications and rules.
- Can I customize the stubs used to generate specifications and rules?
- The published overview does not document stub customization, so inspect the package source for publishable stub files or a config option before relying on it. If stubs are not publishable, you can override them through a forked package or a local path repository. Teams with strict coding standards should agree on the generated class shape up front, since generated code becomes yours to maintain. Also check for conflicts with existing custom stub or code-generation tooling in your project.
- Does MakeRule generate Laravel validation rules or domain business rules?
- Based on the package's positioning around DDD and explicit business-rule modeling, MakeRule targets custom domain rule classes rather than Laravel validation rule objects. That distinction matters: validation rules belong near the HTTP layer, while domain rules express invariants and policies. Generate one class with the command and inspect the stub to confirm the intended contract before rolling it out to other developers.
- How does the package handle namespaces and files that already exist?
- Generated classes are placed according to the namespace and directory conventions the command derives from your application structure. Behaviour when a target file already exists is not described in the overview, so test it in a throwaway branch rather than assuming it will prompt or skip. Namespace collisions are one of the known failure modes for maker commands, so keep your PSR-4 mapping consistent. Make sure the target directories are writable, otherwise generation will fail.
- How should I test the classes generated by this package?
- The package does not appear to ship testing helpers, so write ordinary unit tests against the generated classes. Specifications are easy to cover with data providers that assert isSatisfiedBy returns true or false for representative inputs, and rules can be tested against expected pass or failure outcomes. Keep these tests close to the domain layer, avoiding database or HTTP dependencies where possible. Adding tests also protects you if a package update changes the stubs later.
- Is it safe to adopt in an existing legacy Laravel codebase?
- Adoption is additive and low risk because nothing is migrated or rewritten automatically. The sensible approach is to use the makers only for new features and specifications rather than retrofitting existing controllers. Retrofitting legacy logic is a refactoring project in its own right and should follow your normal test coverage requirements. For greenfield work or new feature slices, the tooling fits naturally into an Artisan-driven workflow.
- Is the package actively maintained, and what are the alternatives?
- Check the GitHub repository and Packagist for recent releases, open issues and Laravel version support before committing to it. Because it is a small maker package, the abandonment risk is mostly cosmetic: generated classes keep working even if updates stop. Alternatives include writing the same scaffolding by hand, using Laravel's built-in make commands plus your own stubs, or adopting a broader DDD package for Laravel. If you need long-term guarantees, consider forking the package and owning the stubs internally.