Laravel Domain Commands Laravel Package

Product Decisions This Supports

• Build vs. buy vs. borrow for developer tooling: the package is a small, MIT-licensed scaffolding helper that generates DDD-style classes (actions, DTOs, repositories, domain models) via Artisan. Decision is less "buy" and more "adopt/fork vs. write our own stubs" — the entire feature set is reproducible with a handful of stub files and a custom make: command.
• Architecture standardization / paved road: if we are asking teams to structure Laravel apps with a domain layer, scaffolding commands reduce the cost of conforming. This directly supports onboarding time and consistency metrics.
• Roadmap sequencing for an internal "platform/DX" initiative: adopting (or reimplementing) this is a days-level effort, not a quarters-level one — useful as a low-risk pilot for a broader internal scaffolding/CLI strategy.
• Not a decision driver for: runtime behavior, security posture, performance, or customer-facing features. This is purely a velocity and consistency lever for engineering.
• Risk flag that shapes the decision: the repo is archived (last release 2023-11-21, 22 stars). Any decision here must be "vendor/fork and own it," never "depend on upstream." That changes the total cost of ownership calculation materially — we inherit maintenance.

When to Consider This Package

Consider it when:

• We have already committed to a DDD-flavored Laravel structure and can point to existing code that matches its conventions.
• We want scaffolding on day one and are prepared to fork, vendor, or copy the stubs into our own codebase — treat it as reference material, not a dependency.
• The team is small and the cost of writing equivalent stubs in-house (likely under a day) is comparable to the cost of adapting this.
• We're evaluating patterns rather than adopting a library — reading its generators is a cheap way to pressure-test our own conventions.

Look elsewhere (or write it ourselves) when:

• Maintenance matters. Archived + no releases since 2023 means no Laravel 11/12 compatibility guarantees, no PHP 8.3+ support, no security patches. Pinning it in a production composer.json is a liability.
• We have compliance, SBOM, or supply-chain review — an abandoned third-party package with 22 stars will not clear it, and shouldn't.
• The team has not agreed on DDD conventions. Scaffolding locks in opinions; adopting tooling before the architectural decision inverts the sequence and creates churn.
• We need anything beyond class stubs — migrations, tests, wiring, module boundaries — the package's scope is narrow.
• We're on a recent Laravel version and unwilling to patch compatibility ourselves.

Recommendation: do not adopt as a dependency. Timebox a spike to read its stub conventions, then implement our own generators in-house (~1 day) so we own the lifecycle.

How to Pitch It (Stakeholders)

To executives: This is a small, free developer-productivity tool that automates repetitive boilerplate when we build Laravel services. It is not customer-facing and carries no license cost. The catch is that the original maintainer has archived it and there have been no updates since late 2023, so we would not run it as-is. The recommendation is to spend roughly one engineering day replicating its useful conventions internally rather than taking on an unmaintained dependency. Net: a minor velocity gain, a minor one-time cost, and no ongoing vendor relationship.

To engineering: The scaffolding commands are a solid reference for how to structure a domain layer, but the upstream is dead — 22 stars, last release November 2023, repo archived, no Laravel 11/12 path. Use it as a pattern library, not a composer require. Copy the stub conventions, wire our own make:domain-* commands into the app skeleton or an internal package, and we get the same ergonomics with a maintainer who actually ships. If someone wants to prototype with it in a throwaway branch to validate the conventions, that's a fine use of a half-day.