Product Decisions This Supports
- Architecture decision: DDD layering vs. default Laravel MVC. This package is a forcing function for the question "do we actually want Domain / Application / Infrastructure separation in this codebase, or do we just want tidier MVC?" It provides opinionated glue (base classes, service providers, likely generators) that makes the DDD choice concrete rather than theoretical.
- Build vs. buy for scaffolding. Every team that adopts DDD in Laravel writes the same ~200–500 lines of plumbing: base aggregate/entity classes, repository contracts, domain event dispatch bridging to Laravel's event system, artisan make-generators. This package is a candidate shortcut for that work — evaluate it against the cost of an afternoon of in-house code.
- Roadmap input for modularization. Relevant when planning a bounded-context split, a team topology change, or extracting a monolith module. Useful as a reference implementation to reason about where domain logic lives before committing to a structure.
- Use-case fit. Highest value where business rules are genuinely complex and anemic models are already hurting — pricing, billing, entitlements, compliance workflows. Low value for CRUD/admin surfaces, where DDD ceremony is pure overhead.
- Migration planning. Supports an incremental strangler-style refactor: introduce domain services alongside existing fat controllers/models rather than a big-bang rewrite.
When to Consider This Package
Consider it if:
- You have already committed to DDD (not still debating it) and specifically want Laravel-idiomatic glue rather than a framework-agnostic DDD library.
- The blast radius is small and reversible — internal tooling, a spike, or a codebase where you are willing to vendor or fork the package and own it.
- Someone on the team will read the source end-to-end before adoption. With this package's adoption signal, source review is not optional.
Look elsewhere — or just write it yourself — if:
- You need production-critical abstraction. Zero stars, zero dependents, a single maintainer on Bitbucket, and a package score of 0 means no community validation, no ecosystem pressure to keep it current, and no realistic expectation of timely fixes. Treat it as unmaintained until proven otherwise.
- Laravel version compatibility is unclear. Laravel majors ship fast and break packages like this. Check
composer.json constraints and test against your actual framework version before anything else.
- You only want folder structure. Directory conventions are a team agreement, not a dependency. Don't take a package to get
app/Domain/.
- You need event sourcing, CQRS, or real query abstraction. Unproven code is the wrong foundation for the parts of your system that are hardest to change later.
- You need a support contract or security responsiveness. There is no vendor here.
Minimum due-diligence gate before any pilot: license, Laravel/PHP version constraints, presence of tests, last commit date, and whether domain events integrate cleanly with Laravel's dispatcher and queue.
How to Pitch It (Stakeholders)
To executives: This is a low-cost experiment, not a platform bet. It's a small DDD helper library for Laravel with essentially no adoption — which means the code is cheap to try and cheap to discard. Recommend a timeboxed spike (1–2 weeks, one bounded context) with a hard rule that we vendor the code and own it if we keep it. Do not frame it as a dependency we're standardizing on.
To engineering: Treat it as a reference implementation and patterns library, not a dependency. The value is in seeing one coherent answer to "how do domain events, repositories, and aggregates wire into Laravel?" — then borrowing the good parts into our own thin internal package. That gets us the architectural clarity without inheriting maintenance risk from a zero-star Bitbucket repo. If the spike shows it saves real time, we fork it and pin it; if not, we've spent a week and learned what our own scaffolding should look like.
Decision requested: approval for a timeboxed evaluation, with adoption contingent on passing the compatibility and source-review gate above.