Weave Code
Ddd Bundle Laravel Package
netteam/ddd-bundle
Netteam DDD Bundle provides a domain-driven design foundation for Laravel/PHP applications, offering shared building blocks and conventions to organize domain, application, and infrastructure layers cleanly.
At a glance
Frequently asked questions about Ddd Bundle
- Is netteam/ddd-bundle a Laravel package or a Symfony bundle?
- It is a Symfony bundle, despite how it is sometimes described. It ships DDD tactical primitives such as entities, value objects, aggregate roots, domain events, repository abstractions, and command/query bus wiring, but ties them to Symfony's bundle lifecycle, DI container, service tagging, and configuration tree. It exposes no Laravel service provider or config surface, so Laravel's package discovery has nothing to register.
- Can I install netteam/ddd-bundle in a Laravel app with Composer?
- You can run composer require, but it pulls in symfony/framework-bundle and related components while giving Laravel nothing to boot. There is no service provider, no publishable config, and no facade, so all wiring would have to be written by hand. The practical recommendation is not to add it as a live dependency and instead treat the source as a pattern reference.
- What DDD building blocks does netteam/ddd-bundle actually provide?
- It offers ready-made base classes for entities, aggregates, and value objects, plus domain event dispatching, repository interfaces to decouple persistence from domain logic, and command/query bus wiring. These are tactical patterns only, not strategic ones like bounded context mapping. Conventions are configurable so the structure can be bent toward an existing project layout.
- Do the bundle's domain events integrate with Laravel's event dispatcher?
- Not out of the box. The bundle is wired against Symfony's event dispatcher through its container configuration, and Laravel's dispatcher is a different contract. To use the pattern in Laravel you would record events on your aggregate and adapt or forward them to Laravel events or a dedicated event bus at the application boundary.
- Which PHP and Laravel versions does netteam/ddd-bundle support?
- There is no documented Laravel support at all, because the package targets Symfony. PHP and Symfony constraints are pinned in its composer.json and should be read directly before any evaluation. Pin nothing until those constraints are confirmed against your target runtime, and budget a time-boxed compatibility spike if you still want to try.
- Is netteam/ddd-bundle actively maintained and safe for production?
- There is no visible maintainer of record, no stars, no dependents, and no release cadence, which means no community validation, no downstream bug reports, and no CVE history. The realistic risk model is that you adopt a fork on day one and own it forever. License terms, commit recency, test coverage, and CI status are unverified gating items that must be closed before it reaches any shortlist.
- Do my domain classes have to extend the bundle's framework base classes?
- The bundle ships framework base classes for entities, aggregates, and value objects, so adopting them directly couples your domain model to its hierarchy and, indirectly, to Symfony. If that coupling is mandatory, the framework-agnostic domain argument collapses. Auditing whether your aggregates must extend or implement bundle types is one of the first checks to run before any extraction.
- What are the best alternatives to netteam/ddd-bundle for DDD in Laravel?
- The usual answer is a thin first-party package, such as app/Domain or an internal acme/ddd-core library, that borrows the vocabulary of aggregate roots, domain events, and repository contracts while using Laravel-native primitives. Laravel service providers, the container, and Laravel events cover most of the wiring the bundle would otherwise do. That keeps DDD off a critical path and avoids a permanent fork obligation.
- How should I test aggregates and domain events if I vendor these classes?
- Unit test aggregates in isolation: construct them, act on them, and assert on invariants plus the domain events they record and release. Then prove the plumbing with one end-to-end spike covering a single aggregate, one invariant, one recorded domain event, and one repository round-trip. If the spike needs more adapter code than domain code, stop and build the internal package instead.
- How do I adopt the bundle's patterns without depending on the package?
- Read the source and extract the API surface worth keeping, then vendor those classes into an internal namespace with attribution and the original license preserved. Replace framework-coupled internals with Laravel equivalents, namely service providers instead of kernel extensions, the Laravel container for wiring, and Laravel events for dispatch. Finally, treat the upstream repository as documentation rather than a versioned dependency so you retain the design intent without a fork obligation.
Weaver
How can I help you explore Laravel packages today?