Ddd Laravel Package

Product Decisions This Supports

• Architecture standardisation across services. Whether to mandate a single DDD layering (Domain / Application / Infrastructure / Presentation) for all new Laravel services, or let teams self-organise. A generator makes a standard cheap to comply with, which is usually the difference between a guideline and a practice.
• Test-strategy standardisation — now bundled with structure. v2.1.0 generates Pest unit and feature tests alongside the layers, and ddd:setup-tests codifies the harness setup. That merges two previously separate decisions: "what shape is a service" and "what does a service's test suite look like on day one." If you are already standardising on Pest, this collapses two standards into one command; if you are a PHPUnit shop, the default generator no longer matches your standard and you are on --legacy-phpunit, which is a materially weaker value proposition.
• Build vs. buy vs. borrow for internal scaffolding. Every mature Laravel org eventually writes its own make:*-style CLI. This package is a candidate "borrow now, fork later" option — it sets a cost baseline against the 2–6 engineer-days of building and maintaining an equivalent internal generator. Test generation raises that baseline: a hand-rolled generator that also emits wired-up Pest unit/feature scaffolding plus a harness-setup command is closer to 5–10 engineer-days, so the borrow case strengthens.
• Greenfield vs. retrofit roadmap calls. Scaffolding tools only pay back at project inception — this remains true and is now sharper, since ddd:setup-tests also implies touching an existing suite's configuration. Retrofit value is near zero; greenfield value went up.
• Onboarding and ramp-time assumptions. A generator encodes conventions as executable artifacts, which shortens time-to-first-meaningful-PR for new hires. With tests included, the first PR can now be "make the failing todo pass" rather than "write the test harness, then the feature" — a measurable reduction in time-to-first-green-build that is worth tracking as an onboarding metric.
• Definition-of-done and code-review standards. This decision got more consequential in v2.1.0. The generator's output is now the canonical example for both structure and tests, and the starter cases ship as explicit todos. Decide deliberately whether "generated todos must be resolved before merge" is your DoD — otherwise you will silently accumulate stub tests that assert nothing and inflate apparent coverage.
• Dependency-footprint policy. Pest is a dev-only dependency and runtime requirements are unchanged, so this does not touch production risk. It does mean the tool now expresses an opinion about your dev toolchain; worth confirming it doesn't collide with an existing parallel test setup.
• Upgrade/major-version call. v2.x is a major bump from the v1 line in circulation, and the default ddd:make Test behaviour changed (Pest by default, PHPUnit behind --legacy-phpunit). For any team already piloting v1, this is a scheduled migration decision, not a silent composer update.
• Use-case triage. Best fit: bounded-context-per-service Laravel 12/13 apps on PHP 8.4+, mid-size domain, team already bought into DDD and Pest. Poor fit: CRUD admin panels, prototypes, single-controller internal tools, PHPUnit-standardised teams, or teams still debating whether DDD is warranted.

When to Consider This Package

Consider it when:

• You are starting new Laravel services and have already committed, organisationally, to DDD as the target structure — the tool accelerates a decision you've made, it does not make the decision for you.
• Pest is, or is about to be, your test standard. This is now the strongest single fit criterion. The test generation is the headline of this release; adopting it on a PHPUnit standard means running the legacy path and forgoing most of the new value.
• You are on Laravel 12 or 13 with PHP 8.4/8.5 — the stated and CI-verified matrix. Anything else is unverified territory and should be treated as a fork-and-fix exercise.
• You have more than one team or more than ~3 services and structural drift is a real cost (cross-service PRs, shared libraries, platform engineers fielding "where does this class go" questions).
• You can own the tool: pin a version, vendor or fork it, and assign a named maintainer. Treat it as source code you adopted, not a dependency you consume.
• You want a cheap experiment — a timeboxed spike on one new service to see whether the generated structure and generated tests survive contact with your actual domain.
• Your team is prepared to delete or rewrite generated code. Generators that produce code you're afraid to edit are a net negative — and generated todo tests are exactly the kind of thing teams are afraid to delete.

Look elsewhere, or don't adopt, when:

• You cannot currently install it. At publication, Packagist still listed v1.1.14 while v2.1.0 was tagged. This is a hard, concrete blocker: composer require may resolve to the old major, or fail to find v2 at all. Verify the index is refreshed before you plan anything; if it isn't, you are installing from a VCS tag, which is a different (and higher-maintenance) commitment. Treat "can a clean composer require in a throwaway project select v2.1.0 today?" as gate zero.
• Social proof matters to your risk model. Zero stars, zero dependents, no downstream consumers remains the core risk: nobody else's production traffic is exercising this code. v2.1.0 improves the picture — an 83-test / 496-assertion suite, a PHP 8.4/8.5 × Laravel 12/13 CI matrix, dependency audits, and integration tests that actually execute generated todos through the real Pest runner. That is unusually rigorous for a package of this size and is genuine evidence of care. It is not evidence of adoption: the maintainer is validating their own code. Acceptable for a dev-time CLI; unacceptable for anything in a runtime path — confirm it is the former (the notes say dev-only, but verify).
• You need vendor support, SLAs, or a security review trail. A single-maintainer package will not clear most enterprise procurement gates without an internal fork and an owner.
• The team hasn't adopted DDD, or hasn't adopted Pest. A generator applied to a team that doesn't believe in the layering produces ceremony: empty domain folders, anaemic models, and a slow drift back to Laravel default structure. The test equivalent is worse, because it looks like coverage. Fix the conviction first.
• You are mid-flight on v1. The major-version jump plus a changed default for ddd:make Test means an upgrade needs a deliberate plan and a read of the v2.0.0 notes, which were not included in this release brief.
• Abandonment risk is unacceptable. With no dependents there is no natural successor maintainer and no community pressure to keep it working across Laravel majors. The stated Pest 4↔Laravel 12 / Pest 5↔Laravel 13 pairing means this package is now coupled to two fast-moving majors, which raises ongoing maintenance load relative to v1. Your exit plan is still "fork it," so budget for that.

Due diligence before any pilot: confirm the Packagist index lists v2.x (gate zero above); obtain the v2.0.0 changelog and any upgrade notes to understand the full breaking-change set, not just the test-default flip; pin the exact version and re-audit release history — the previously recorded last release date (2026-10-03) still reads as a forward-dated or metadata artifact and needs explaining. Re-confirm the scope of what it writes (files only? migrations? service providers? namespace rewrites? Pest configuration?), whether it is idempotent, and what "without replacing existing Pest/TestCase files or application PHPUnit settings" actually covers in your repo layout — the tests/ vs Tests/ discovery behaviour is exactly the kind of thing that surprises people on case-sensitive filesystems and CI. Finally, run the generated suite in your own CI, not just locally, before trusting the "fails safely" claims on invalid paths, symlink escapes and duplicate outputs.

How to Pitch It (Stakeholders)

To executives — one paragraph:

This is a small, free, open-source scaffolding tool that generates the standard folder, class and test structure for a Laravel service built with Domain-Driven Design. The business case is not the tool — it's consistency. Every new service we start today re-litigates where code goes and how its tests are set up, and that shows up as slower onboarding, more review churn, and platform engineers answering the same structural questions. A generator turns our architecture and testing standards from a wiki page into a command, for a few days of engineering effort. The new release is a meaningful step up: it also scaffolds unit and feature tests and sets up the test harness, and it ships with a real CI matrix across two Laravel and two PHP versions — which tells us the maintainer is serious, though it still tells us nothing about who else uses it. Two honest caveats: the package has essentially no external users, so we would be adopting it as source code we own; and the public package index hasn't caught up with the new version yet, so installation is currently unproven. Recommend a one-service, one-sprint spike with a kill criterion before any org-wide mandate.

To engineering leads — the short version:

• What it buys: boilerplate elimination and enforced layer boundaries at service creation; Pest unit and feature test scaffolding wired to the right TestCase; a one-shot harness setup that preserves your existing Pest/TestCase files and PHPUnit settings; a canonical reference implementation for reviews; faster ramp for new hires.
• What's new in v2.1.0: test generation for both new and legacy domains, tests included automatically in new domains/full/API modules/CRUD scaffolds, safe-fail behaviour on invalid paths and duplicate outputs, and a validated CI matrix (PHP 8.4/8.5 × Laravel 12/13, 83 tests / 496 assertions, integration tests that run the generated fixtures through the real Pest runner).
• What it costs: near-zero licence cost, low integration cost (dev-time CLI, Pest as a dev dependency only — production requirements unchanged), but real ownership cost — treat it as a fork-first dependency, and note it now tracks two fast-moving majors (Pest and Laravel).
• What we're not claiming: it is not a DDD teacher and it won't fix a team that hasn't bought into the layering; generated starter cases are explicitly todos and are not business coverage — do not let them into a coverage metric. It removes typing, not thinking.
• Watch-outs: v2 is a major bump with a changed default for ddd:make Test (Pest now, --legacy-phpunit for the old behaviour) — anyone on v1 migrates deliberately, not via composer update. Packagist still advertised v1.1.14 at publication, so confirm a clean install resolves v2.1.0 before committing.
• Ask: a timeboxed spike on one new service, measured against our current manual setup — hours-to-first-endpoint, hours-to-first-green-test-suite, and whether the generated structure and tests survived the first week of real feature work. If it doesn't clear that bar, we build the internal generator ourselves and lose nothing but the spike.