- Is geekcell/ddd-bundle a Laravel package or a Symfony bundle?
- It is a Symfony bundle. The repository is named ddd-symfony-bundle and the package ships a Bundle subclass, a dependency-injection extension, and compiler passes, none of which Laravel boots. The DDD concepts inside it are framework-agnostic, but the packaging targets Symfony. Treat any listing that calls it a Laravel package as inaccurate until you verify the source yourself.
- Can I install geekcell/ddd-bundle in a Laravel application with Composer?
- Composer may resolve because Laravel 11 and 12 already pull Symfony components such as console, http-foundation, routing, and error-handler. The blocker is any requirement on symfony/framework-bundle or symfony/http-kernel, which drags in the full Symfony kernel. Even when installation succeeds, the package is inert in Laravel: no service provider registers it, no config tree is read, and no compiler passes run.
- Which Laravel versions does geekcell/ddd-bundle support?
- None officially. It declares Symfony and PHP constraints, not illuminate or Laravel constraints, and there is no Laravel service provider in the codebase. Laravel 11 and 12 ship Symfony 7 components, so some overlap may resolve, but that is incidental version compatibility rather than Laravel support. Check composer.json for framework-bundle and http-kernel requirements before assuming anything works.
- What DDD building blocks does the bundle actually provide?
- It offers tactical primitives: aggregate roots, entities, value objects, domain events, repository interfaces, and UUID identifiers. In Symfony it also supplies the wiring that binds interfaces to implementations and auto-registers handlers and subscribers. That wiring, not the primitives, is where most of the bundle's practical value sits, and it is exactly the part that does not transfer to Laravel.
- How would I port the bundle's repositories and domain services to Laravel's container?
- You would rewrite the integration surface rather than adapt it. Replace the Bundle class and extension config tree with a ServiceProvider and a config/ddd.php file, and replace compiler passes with explicit bindings and contextual binding. Symfony's attribute or annotation scanning for auto-registration has no direct Laravel equivalent, so use explicit registration or a discovery package. Budget for this as port-and-vendor work, not an install.
- Is geekcell/ddd-bundle still maintained?
- The repository is archived, with roughly 13 stars, zero dependents, and a last release around February 2025. An archived repo means no security response and no PHP or Symfony compatibility work going forward. The MIT license gives you legal cover to fork, but it gives you no engineering cover. Low adoption plus the package-name and repo-name mismatch also suggests an internal-extracted project rather than a maintained library.
- How much of geekcell/ddd-bundle is pure PHP versus Symfony-coupled?
- That is the decisive question and it can only be answered by reading the source. Produce a file-level dependency map of src/ and check whether the domain primitives themselves extend or type-hint Symfony contracts. If src/Domain is free of Symfony imports, lifting it into Laravel is realistic; if the primitives are coupled, extraction cost rises sharply. Also check whether a test suite exists that you can run standalone against the extracted code.
- Does geekcell/ddd-bundle handle domain events and transactions, including after-commit or an outbox?
- You need to verify this in the source before relying on it, since documentation for an archived package should not be trusted. Check whether domain events are dispatched synchronously in-process and whether any after-commit or outbox concept exists. If it depends on a command or query bus, determine whether that bus is first-party or a third-party dependency, because that adds another library to your stack. In Laravel you would likely pair events with database transactions and queued listeners instead.
- What are the alternatives for applying DDD in Laravel?
- The cheapest option is framework-native: plain PHP domain classes, repository interfaces bound in a ServiceProvider, and Laravel events for domain events. That covers most tactical DDD needs without a package. If you want a library, benchmark actively maintained Laravel-focused options and cross-framework packages against your requirements before writing code. The bundle itself works better as a pattern reference than as a dependency.
- Should I use geekcell/ddd-bundle in a production Laravel application?
- No. It is archived, unmaintained, and packaged for a framework Laravel does not boot, so you would own all future maintenance from day one. Running retained Symfony wiring inside a Laravel process also means two container and event idioms with two upgrade cadences, which is a persistent cognitive tax. If you want the patterns, vendor the primitives you can verify as pure PHP and leave the Symfony integration behind.