Laravel Ddd Laravel Package

Product Decisions This Supports

• Architecture direction: whether to adopt tactical Domain-Driven Design (aggregates, value objects, domain events, repositories) inside a Laravel codebase. This package is the cheapest way to trial that decision — it scaffolds the building blocks without changing the framework or runtime.
• Build vs. buy (or buy vs. write stubs): the alternative is maintaining your own set of stub files and make:-style commands. teylabs/laravel-ddd is a thin codegen layer over Laravel's existing generators, so the buy case rests on convention consistency across squads, not on unique capability.
• Roadmap / modularization bets: if the roadmap includes splitting a monolith into bounded contexts, ddd:* generators let you prototype context boundaries in a branch and measure the cost of the structure before committing to a migration epic.
• Onboarding and velocity: new hires get a canonical file layout (Domain/<Context>/{Aggregates,Events,ValueObjects,...}) instead of reading three legacy modules to infer where things go. Useful when staffing parallel workstreams.
• Release process decisions (v3.3.0 specifically): the exit-code change means any CI script, Makefile, or wrapper that does if ddd:aggregate Foo; then ... to detect "class already exists" now silently changes behavior. This is an internal tooling decision — audit and update those scripts before upgrading, or pin to 3.2.x.
• Eventing conventions: ddd:listener --event=InvoicePaid now resolves to the domain event (Domain\Billing\Events\InvoicePaid) rather than App\Events\.... That is a deliberate opinion: domain events are the default, application events are the exception and must be fully qualified. If your product architecture keeps events in the app layer, this default works against you.

When to Consider This Package

Adopt when:

• You are on a current Laravel version and already use (or plan to use) make:* generators as part of normal workflow — this slots in beside them rather than replacing them.
• Multiple developers or squads need a shared, non-negotiable file layout so code review can focus on behavior instead of placement.
• You want the structure without the cost of writing and maintaining your own stubs and generator commands.
• You are running a bounded pilot (one context, one squad) and want an exit ramp: nothing here changes runtime, so removal is a delete-the-dev-dependency operation.

Look elsewhere when:

• You need enforcement, not just scaffolding — use deptrac, PHPArkitect, or PHPStan architecture rules for dependency-direction guarantees. This package will happily generate a class; it will not stop you from importing it where you shouldn't.
• You are not committed to DDD. Generating Domain/ folders without domain modeling discipline produces ceremony without benefit.
• You depend on exit codes for generator behavior in automation (see the v3.3.0 change) and cannot absorb a maintenance pass right now.
• You need a vendor SLA, security review process, or long-term support commitment. This is a single-maintainer package on a small release cadence (v3.2.2 → v3.3.0), which is a governance risk for a large org, mitigated by its dev-only footprint.
• Your event/listener wiring is centralized in the application layer. The new domain-first default for --event is a mismatch you'd be fighting on every invocation (you can pass a fully qualified name, including one picked from the interactive prompt, but the default nudges the wrong way for you).

How to Pitch It (Stakeholders)

One-line summary: a small, dev-only Laravel package that generates DDD scaffolding (aggregates, value objects, domain events, listeners) so teams produce consistently structured code faster and with less review churn.

To engineering leadership: it is a convention tool, not a framework. It adds no runtime dependency, no request-path code, and no migration burden — which makes the decision low-risk and reversible. The trade-off is a single-maintainer dependency and a modest release cadence; acceptable because it lives in require-dev.

To engineering teams: you get make:*-style commands for domain building blocks, with interactive prompts and a predictable folder contract. Two things changed in v3.3.0 that you should know before upgrading: (1) ddd:* commands now exit 0 when a class already exists or a name is reserved by PHP, matching make:* — the error is still printed and your file is untouched, but any script relying on the old non-zero exit should check output instead; (2) ddd:listener --event=InvoicePaid now binds to the domain event, so pass a fully qualified name like --event="App\Events\InvoicePaid" for application events.

To product management: the value is lead time on new domain features and reduced onboarding cost; the cost is one dependency and a small amount of up-front agreement on folder conventions. Recommend a one-context pilot rather than a mandate.

Risk posture: low blast radius, medium maintenance exposure. Upgrade action item for v3.3.0 is a grep of CI scripts and Makefile targets for ddd:* invocations that branch on exit status.