Symfony Bridge Laravel Package

Product Decisions This Supports

• Architectural Shift to Event-Driven & CQRS Patterns: Enables adoption of Command Bus (for explicit actions) and Event Bus (for reactive workflows), aligning with modern microservices and decoupled architectures.
• Symfony Monolith-to-Microservices Migration: Facilitates gradual decomposition by isolating business logic into discrete commands/events, easing future service splitting.
• Build vs. Buy: Avoids reinventing message bus infrastructure (e.g., custom Symfony event dispatchers or RabbitMQ integrations) while maintaining flexibility.
• Use Cases:
  • Asynchronous workflows (e.g., order processing, notifications).
  • Audit trails (via event sourcing).
  • Decoupled services (e.g., separating payment processing from UI).
  • Testing isolation (commands/events can be mocked/stubbed independently).

When to Consider This Package

• Adopt if:

  • Your Symfony app needs explicit command handling (e.g., "ProcessPaymentCommand") or event-driven reactivity (e.g., "OrderCreatedEvent").
  • You’re avoiding direct Symfony services in business logic (e.g., no ContainerInterface in domain models).
  • You want testability (commands/events are pure PHP, easy to unit test).
  • Your team is familiar with CQRS/Event Sourcing or wants to learn it incrementally.
  • You’re using Doctrine ORM (the bridge includes a bundle for entity hydration).

• Look elsewhere if:

  • You need real-time pub/sub (consider Symfony Messenger + AMQP).
  • Your use case is simple event dispatching (Symfony’s built-in EventDispatcher may suffice).
  • You’re not using Symfony (this package is Symfony-specific).
  • You require enterprise-grade scalability (e.g., Kafka; this is lightweight).
  • Your team lacks PHP/DDD experience (steep learning curve for new concepts).

How to Pitch It (Stakeholders)

For Executives: "This package lets us build more scalable, maintainable Symfony apps by separating business logic into discrete commands and events—like sending an email as a 'SendEmailCommand' instead of calling a service directly. It’s a lightweight way to adopt modern architectures (CQRS, microservices) without heavy infrastructure costs. Think of it as ‘Symfony’s built-in message bus’: easier to test, decouple, and scale than custom solutions."

For Engineers: *"SymfonyBridge gives us two key bundles:

1. CommandBusBundle: Turns Symfony into a command processor (e.g., bus->handle(new CreateUserCommand())).
2. EventBusBundle: Decouples event publishing (e.g., bus->dispatch(new UserCreatedEvent())) from subscribers. It’s battle-tested (used in SimpleBus), integrates with Doctrine, and avoids Symfony’s tight coupling. Perfect for:

• Moving away from service containers in domain logic.
• Adding async workflows (e.g., background jobs via event listeners).
• Preparing for microservices without rewriting everything."*

Key Asks:

• Devs: "Can we trial this for one feature (e.g., user onboarding) to compare dev velocity vs. custom solutions?"
• Architects: "How does this fit with our long-term event-sourcing goals?"
• Ops: "What’s the overhead vs. existing message queues (e.g., RabbitMQ)?"