Laravel Domain Commands Laravel Package

Getting Started

This package is a scaffolding helper: it generates the boilerplate classes for a domain-oriented (DDD-ish) Laravel codebase so you don't hand-create folders and namespaces. Treat it as a code generator, not a runtime dependency.

1. Confirm compatibility before installing. The repo is archived and the last release was November 2023, so check its composer.json constraints against your Laravel/PHP version. If you're on a newer Laravel major, expect to fork or pin.
2. Install as a dev dependency if you only use it to generate files:

   composer require --dev signifly/laravel-domain-commands
   

3. Discover the actual command surface first. Do not assume command names from the README:

   php artisan list | grep -i domain
   php artisan help <command-name>
   

4. Publish any config/stubs the package exposes, then inspect the defaults:

   php artisan vendor:publish --provider="Signifly\DomainCommands\...ServiceProvider"
   

   (Use php artisan vendor:publish --list if the provider/tag isn't obvious.)
5. First use case: scaffold one small bounded context end-to-end — e.g. Billing — generate one action/class, open the generated file, and verify the namespace and path match your app's composer.json autoload. Only then generate the rest of the domain.

The first thing to read is the package's src/ command classes and stubs, not just the README. With an archived 22-star package, the source is the documentation.

Implementation Patterns

Decide your domain layout before generating anything. The package just writes files to configured paths; if your team hasn't agreed on app/Domain/{Context}/{Layer} vs src/{Context}/..., you'll generate inconsistent code. Configure paths once, commit that config, and treat it as the contract.

Generate per bounded context, not per Laravel artifact. The workflow that pays off day-to-day:

• Create a context (e.g. Sales) and scaffold its actions, DTOs, events, and exceptions in one pass.
• Add new behavior by generating a single-purpose action class, then wiring it from a controller, job, or console command.
• Keep generated classes thin and invokable; put orchestration in the action, persistence at the edges.

Wrap generation in a repeatable script. Because the package is archived and its command signatures are fixed, hide it behind a Makefile or Composer script:

"scripts": {
  "make:action": "php artisan <domain-command>"
}

This makes it trivial to swap the generator later without rewriting team habits.

Integrate at the edges. Controllers, form requests, jobs, and console commands should call into generated domain classes; they shouldn't contain domain logic themselves. Bind domain services/repositories in a dedicated service provider. If you're pragmatic DDD, it's fine for Eloquent models to live inside the domain folder — just be consistent.

Enforce the boundaries you're scaffolding. Generation alone doesn't create architecture. Add Pest/PHPUnit architecture tests (e.g. Pest's arch()) that assert domain namespaces don't depend on HTTP or facade-heavy code. This is the single highest-value complement to a scaffolder.

Review generated diffs like handwritten code. Don't regenerate in CI. Generate locally, edit the output (add declare(strict_types=1), final, return types), and commit. The generator only gets you 60% there.

Gotchas and Tips

• Archived means frozen. No Laravel 11/12 fixes, no security patches, no new commands. Budget for a fork if you adopt it long-term. Check the GitHub issues for known breakages before upgrading Laravel.
• Command names and signatures are not guaranteed by the README. Always use php artisan list and php artisan help <command>. If help errors, the command may have been renamed between the README and the release.
• Config caching bites. After changing generated paths/namespaces in config, run php artisan config:clear. In production-like environments a cached config will silently use old paths.
• Autoload mismatches. New namespaces outside App\ won't resolve until you update composer.json and run composer dump-autoload. If a generated class "doesn't exist," this is usually why.
• Naming is namespace-critical. Domain and class names become PHP namespaces. Use StudlyCase, avoid reserved words (Class, List, Trait), and avoid names that collide with Laravel classes.
• Generators often skip existing files. If a command appears to "do nothing," the target file may already exist. Check with -v verbosity and inspect the target directory before rerunning.
• Permissions and path errors are quiet. Ensure the target directories are writable; a failing mkdir may surface as a cryptic or silent failure.
• Stubs are opinionated. Generated classes may lack strict types, final, or your preferred constructor style. Publish/override stubs if supported; otherwise, fork the package and edit the stub files — it's a small codebase, so forking is realistic.
• Don't over-generate. Empty scaffolded classes rot fast. Generate a class when you're about to fill it in, not "for completeness."
• Extension points are limited: published config (paths/namespaces), published stubs (if exposed), and the service provider. There is no plugin system; for anything beyond that, fork.
• Debugging approach: run the command with -v, inspect the exact path written, check composer dump-autoload, then check config cache. That sequence resolves most "it generated nothing / class not found" reports.