Weave Code
Laravel Domain Commands Laravel Package
signifly/laravel-domain-commands
Artisan commands for scaffolding domain-driven design in Laravel. Quickly generate domains, actions, and supporting classes with a consistent structure, so business logic stays organized and your codebase remains easy to navigate and extend.
Artisan commands to scaffold DDD classes in your Laravel app
Frequently asked questions about Laravel Domain Commands
- How do I install signifly/laravel-domain-commands?
- Install it as a dev dependency with composer require --dev signifly/laravel-domain-commands, then register the package's service provider in non-production environments only. There are no database, queue, or infrastructure changes involved. Because the repository is archived, pin the exact version and commit your lockfile rather than using a floating constraint.
- What Laravel and PHP versions does the package support?
- The last release was on 2023-11-21 and the repository is now archived, so support for current Laravel and PHP majors is unlikely to have been validated. Composer's version constraints will tell you what the package claims, but you should run a short spike against your actual stack before adopting it. Treat any successful install on a newer framework as unverified until your own smoke test passes.
- Which classes does laravel-domain-commands generate?
- It provides Artisan generators for DDD-style artifacts such as domains, actions, domain commands, handlers, and queries. The intent is to encode a consistent layered structure so business logic stays organized and easy to navigate. You should generate a sample of each type in a throwaway branch and compare the output shapes against your own conventions before committing to the tool.
- Is it safe to use in production?
- Yes, in the sense that it has effectively zero production footprint: it emits code at development time and does not execute at runtime. Best practice is to install it with require-dev and exclude it from production builds and container images. The worst realistic failure is a broken scaffolding command, not a production incident, which keeps the blast radius small and reversible.
- Can I customize the generated stubs and namespaces?
- The package description does not document publishable config or stubs, so this needs to be confirmed by inspecting the package source. If the stubs are hard-coded to Signifly's conventions, you would need to fork the package and edit them. Confirm this early, because it determines whether the tool can match your namespaces or only theirs.
- The package is archived. Should I still use it?
- Archival is the dominant risk: there are no upstream fixes, no compatibility updates, and no security triage, so any defect becomes yours to patch. That is acceptable for a low-impact dev-only generator if you fork it and take ownership, but risky if you expect it to track Laravel releases indefinitely. Also expect dependency scanners to flag an archived dependency during audits.
- Is there a maintained fork or alternative package?
- There is no successor package identified in the available information, and community validation is thin at roughly 22 stars. The pragmatic alternatives are maintaining your own fork of this package or writing a small in-house Artisan generator that matches your exact conventions. For a one-time bootstrap, an in-house generator is often cheaper than adopting an unmaintained dependency.
- How do I catch breakage after a Laravel upgrade?
- Add a CI job that installs dependencies and runs each generator as a smoke test so that changes to service provider registration, console command signatures, or stub syntax surface immediately. Pin the package version exactly and commit the lockfile. This turns a silent mid-sprint failure into a clear signal during the upgrade itself.
- Does it fit a legacy codebase with existing conventions?
- Generally no. The generators are designed to encode a DDD or hexagonal layering convention, and in a codebase with established, divergent structure they will produce scaffolding that does not match the surrounding code. It fits greenfield or early-stage services where the layering is still being defined. For legacy apps, evaluate it in a throwaway branch and compare output before deciding.
- Does it depend on other Signifly packages or an assumed base architecture?
- The overview does not state any dependency on other Signifly packages, but it does assume you have committed to a DDD-style layering convention. Teams without an agreed layer structure will get inconsistent scaffolding from the generators. Check the composer.json requirements and the generated class shapes during your spike to confirm what, if anything, is presupposed.
Weaver
How can I help you explore Laravel packages today?