A new module in a properly layered Laravel app means a model, a factory, a repository, a service, a controller, two request classes, a resource, a collection, a DTO, a policy, an observer, a service provider, and a feature test. Eleven-plus files, every one of them needing to agree with the others about naming, about what extends what, about which base class owns which responsibility. Writing that by hand, correctly, from memory, every time you add a domain concept, is exactly the kind of task that either gets done sloppily under deadline pressure or gets copy-pasted from the last module that looked similar — which is the same copy-paste habit the first post in this series was about, just moved one level down.
I know exactly how this goes wrong, because I did it wrong for years before I fixed it. Someone builds the fourth module of the sprint at 5pm on a Friday, copies the third module’s files, renames things, and misses one — the Policy stays a copy of the wrong domain’s rules, and it’s not caught until an authorization bug ships that nobody would have written on purpose. The bug isn’t in anyone’s judgment. It’s in asking a human to correctly retype the same eleven-file skeleton for the fortieth time and never once vary from the pattern.
core:make {Name} is the answer that isn’t “be more careful.” One command generates the entire module, wired to extend every relevant base class correctly, with the naming conventions applied consistently, the service already returning a BaseDataObject instead of a raw array, the resource already exposing fields() instead of tempting you to override toArray(). It’s not a boilerplate generator in the sense of “saves you typing.” It’s a guarantee generator — the thing it produces is structurally incapable of skipping a layer or naming something inconsistently, because the template that generates it already encodes every rule from the rest of this series.
php artisan core:make Orderapp/Modules/Order/
├── Models/
├── Repositories/
├── Services/
├── Http/
│ ├── Controllers/
│ └── Requests/
├── Resources/
├── Policies/
└── Providers/Every file already extends the right base class. The service already returns a BaseDataObject. The resource already exposes fields(). Nothing to remember, because there was nothing left to retype.
This is the clearest case for a paid tier that I can make, because it’s the most measurable one. The architecture tells you what correct looks like. Scaffolding is the thing that gets you there in seconds instead of the twenty-to-thirty minutes it takes an experienced engineer to hand-assemble eleven files correctly — and considerably longer for anyone newer to the codebase. Multiply that by every module your team builds this quarter, and the time back is not subtle. It’s the clearest “this pays for itself” argument in the entire package, which is exactly why it sits in the tier that’s actually priced.
I use core:make on every module I’ve built since I wrote it, including inside this very package’s own source. It is not a demo feature. It’s the tool I reach for before I write the first line of business logic, every time, because retyping a skeleton I’ve already gotten right once is not where I want to spend Friday afternoon.
Get it at https://packagist.org/packages/rupeshstha/core-foundation — part of the core-foundation Pro tier. Both presets and the full generated file list: Scaffolding (core:make)