Weave Code
Ddd Symfony Bridge Laravel Package
becklyn/ddd-symfony-bridge
Symfony bridge for becklyn/ddd-core and becklyn/ddd-doctrine-bridge. Wires SimpleBus command and event buses into your app via bundles, auto-registers subscribers and handlers, and sets up the Doctrine-backed event store.
Integrates components provided by becklyn/ddd-core and becklyn/ddd-doctrine-bridge with a Symfony application
Frequently asked questions about Ddd Symfony Bridge
- Does becklyn/ddd-symfony-bridge work with Laravel?
- No. It is a Symfony bundle, not a Laravel package: it registers SimpleBusCommandBusBundle, SimpleBusEventBusBundle and BecklynDddBundle in bundles.php and ships no ServiceProvider, publishable config, facade or Eloquent adapter. becklyn/ddd-core and becklyn/ddd-doctrine-bridge are Doctrine-coupled at the contract level, so only the architectural pattern transfers to Laravel. A real port means replacing the DI bridge and SimpleBus with Laravel's bus contracts and either adding laravel-doctrine or writing a new event-store adapter, which is realistically 4 to 8 engineer-weeks plus permanent ownership.
- How do I install and configure becklyn/ddd-symfony-bridge?
- Run composer require becklyn/ddd-symfony-bridge, then add SimpleBusCommandBusBundle, SimpleBusEventBusBundle and BecklynDddBundle to config/bundles.php with the all environment. Next add the command_handler and event_subscriber service globs to services.yaml so your handlers and subscribers are auto-tagged. If you want the event store, run php bin/console doctrine:migrations:migrate. On Symfony 6.4 or 7.4 with Doctrine ORM 3 this is a matter of days, not weeks.
- Which Symfony, Doctrine and PHP versions does it require?
- It targets PHP 8.2+, Symfony ^6.4 || ^7.4, Doctrine ORM 3 and DBAL 4. The package is pinned in a three-way group with becklyn/ddd-core ^4.0 and becklyn/ddd-doctrine-bridge ^3.0, and those versions move as a unit. A lag in any one sub-package blocks the whole application's framework upgrade, so pin all three together in a grouped dependency rule.
- How do I disable the Doctrine event store?
- Set the use_event_store option to false in the BecklynDddBundle configuration. That removes the migration, the serializer normalizer surface and most of the operational risk around the bridge. Most teams only need an event bus for fact dispatch rather than event sourcing or replay, in which case disabling the store is the right default.
- How are command handlers and event subscribers auto-registered?
- You add two globs to services.yaml: resource '../src/**/*Subscriber.php' tagged event_subscriber and resource '../src/**/*Handler.php' tagged command_handler, both with public: true and register_public_methods: true. The catch is that this silently tags any class with that suffix, including report handlers, file handlers and test doubles, and the README explicitly warns about it. Suffix conventions rarely survive a growing codebase, so verify the tagged services with debug:container after every refactor.
- Why does my event store migration fail or throw on the first commit?
- The event-store tables come from a Doctrine migration supplied by becklyn/ddd-doctrine-bridge, and you must run php bin/console doctrine:migrations:migrate to create them. Skipping that step throws on the first commit that carries events. This is documented as a footnote in the README rather than enforced as a guardrail, so add it to your deployment checklist.
- Do I need extra serializer normalizers for enum and DateTime payloads?
- Yes. Without the BackedEnumNormalizer and PropertyNormalizer service blocks in services.yaml, tagged serializer.normalizer, enum and DateTime payloads degrade silently when persisted to the event store. If you want Doctrine ORM to keep microseconds in domain event timestamps you also need the DBAL type override described in the README. All three are plain config, but nothing fails loudly if you forget them.
- What happens if multiple handlers are registered for the same command?
- The README warns that more than one handler for a single command either throws exceptions or behaves unpredictably. Treat a second handler as a design error rather than a feature and keep exactly one command handler per command class. This is another hazard documented as a footnote instead of being enforced by the bridge.
- How do I test command handlers and event subscribers built on this bridge?
- There is no Laravel test coverage and none is applicable, so lean on plain unit tests: instantiate the handler or subscriber directly and mock the SimpleBus command bus or the event bus. For integration coverage, boot the Symfony kernel with the three bundles registered and let the real buses dispatch. Watch out that test doubles whose names end in Handler.php are auto-tagged by the services.yaml globs, so exclude test directories from those resource patterns.
- Is it actively maintained, and what should I use instead?
- The adoption signal is effectively null: 0 stars, 0 dependents and a single vendor in Becklyn, an agency, so support means reading the source and bus factor is a genuine planning input. Symfony Messenger is the better-supported primitive, with a failure transport, native retry semantics and a standard worker model, while EventSauce or spatie/laravel-event-sourcing fit event-sourcing needs better outside Symfony. Moving off SimpleBus later is not a config change; it means rewriting every handler registration and middleware.
Weaver
How can I help you explore Laravel packages today?