Weave Code
Laravel Ddd Laravel Package
lunarstorm/laravel-ddd
A Laravel toolkit for domain-driven design: scaffold bounded contexts, aggregates, value objects, events, and commands with Artisan generators, plus conventions and service providers for keeping complex apps modular and maintainable.
Toolkit for domain driven design (DDD) in Laravel. Provides artisan commands to generate domain models, DTOs, view models, value objects, and much more.
Frequently asked questions about Laravel Ddd
- What is lunarstorm/laravel-ddd and what does it do?
- lunarstorm/laravel-ddd is a developer-tooling package that adds Artisan generators and conventions for domain-driven design in Laravel. It scaffolds bounded contexts, aggregates, value objects, DTOs, view models, events, listeners, and commands into a Domain namespace. It complements Laravel's native make:* commands rather than replacing service-container, queue, or event behavior, so its value is realized at code-generation time.
- How do I install lunarstorm/laravel-ddd in a Laravel application?
- Install it with composer require --dev lunarstorm/laravel-ddd, since it is build-time tooling rather than a runtime dependency. The service provider is auto-discovered, so manual registration is usually unnecessary. Run php artisan list afterward to confirm the ddd:* commands are available. Check whether the package ships publishable stubs or config before customizing output.
- Which Laravel and PHP versions does laravel-ddd support?
- The package targets Laravel applications running on PHP 8.x, and the v3.3.0 release notes should be checked for explicit framework constraints. Because it only emits standard PHP classes, it generally tracks current Laravel releases rather than pinning tightly. Confirm the composer.json constraints before upgrading across a major Laravel version.
- What Artisan commands does the laravel-ddd package provide?
- The package provides ddd:* Artisan generators for domain models, aggregates, value objects, DTOs, view models, events, listeners, and commands. Each generator writes a class into the conventional Domain context namespace. Generators can be run ad hoc or scripted in CI and scaffolding workflows.
- Does laravel-ddd add runtime overhead or production dependencies?
- No; it is developer tooling, so generated code is plain PHP that you own and commit, and the package adds no runtime service-container or event-bus coupling. That keeps adoption reversible, since removing the Composer dependency leaves your generated domain classes intact. Production behavior is determined by your application code, not by the generator package.
- How does ddd:listener resolve the --event option in v3.3.0?
- In v3.3.0, ddd:listener --event=InvoicePaid resolves to Domain\...\Events\InvoicePaid instead of App\Events\InvoicePaid. That is a behavioural change from v3.2.x and can silently wire a listener to the wrong event. Pass a fully-qualified class name such as --event="App\Events\InvoicePaid" to have it honoured verbatim. Interactive suggestions now display qualified names as well.
- Why do ddd generators exit with code 0 when a class already exists?
- v3.3.0 aligns ddd:* exit codes with Laravel's make:* commands, so a generator returns 0 when the target class already exists or the name is a PHP-reserved word. The file is still left untouched and the error is still printed, but scripts branching on a non-zero exit code will now treat the no-op as success. Audit any Makefile, CI job, or wrapper that detects existing classes via exit status.
- Can I customize the domain namespace or published stubs?
- The package enforces a convention such as Domain\<Context>\Events, and whether the root namespace is configurable should be confirmed in the package config or publishable stubs. You can typically override generated output by publishing stubs. Verify this against the repository documentation before standardizing a custom layout across a team.
- How do I upgrade from laravel-ddd v3.2.x to v3.3.0 safely?
- Upgrade with a routine composer update, then audit build tooling for ddd:* invocations. Grep CI configs, Makefiles, composer.json scripts, and shell wrappers for exit-status logic and for --event= values without a namespace separator. Rewrite bare event names to fully-qualified class names and refresh onboarding docs and runbooks. Already-generated application code is unaffected by the v3.3.0 changes.
- Is laravel-ddd actively maintained, and what are the alternatives?
- The package is a small, single-maintainer tool, so weigh bus factor and check recent commit activity and test coverage before adopting it in a critical build pipeline. Alternatives include hand-rolled Artisan make:* stubs, custom generator packages, or broader modular-monolith tooling. Because laravel-ddd imposes no runtime coupling, trying it and removing it later is low risk.
Weaver
How can I help you explore Laravel packages today?