Common Laravel Package

Product Decisions This Supports

• Event-Driven Architecture (EDA) or CQRS Adoption: If your roadmap includes implementing domain-driven design (DDD) patterns, event sourcing, or CQRS, this package provides foundational utilities (e.g., event dispatching, message serialization) to reduce custom boilerplate. Aligns with initiatives to decouple services or migrate legacy monoliths.
• Build vs. Buy for Core Infrastructure: Avoid reinventing low-level abstractions (e.g., message buses, event stores) by leveraging this package’s shared utilities. Justifies investment in Prooph’s ecosystem if you’re already evaluating their event-store or service-bus packages.
• Microservices or Modular Monolith: Simplifies cross-cutting concerns like message validation, metadata handling, or payload serialization across distributed components. Critical for teams prioritizing loose coupling or gradual microservices decomposition.
• Legacy System Modernization: If migrating from procedural PHP to modern DDD/ES patterns, this package’s battle-tested utilities (e.g., Message, Metadata) can accelerate refactoring without breaking existing integrations.

When to Consider This Package

• Adopt if:

  • Your team is already using or evaluating Prooph’s event-store, service-bus, or event-sourcing packages (this is their shared dependency).
  • You need standardized message formats (e.g., for inter-service communication) and want to avoid custom serialization logic.
  • Building a new greenfield project with DDD/ES principles from day one (reduces early-stage technical debt).
  • Your stack includes PHP 8.1+ and you’re comfortable with modern OOP practices (e.g., interfaces, generics).

• Look elsewhere if:

  • You’re not adopting event-driven patterns—this package is niche for non-EDA use cases.
  • Your team lacks PHP expertise or prefers framework-agnostic solutions (e.g., Symfony Messenger, RabbitMQ clients).
  • You need real-time features (this is a utility layer, not a pub/sub implementation).
  • Your project is highly constrained by performance (this adds minimal overhead, but not a bottleneck solver).

How to Pitch It (Stakeholders)

For Executives: "This is a ‘plumbing’ package that lets us focus on business logic rather than reinventing message-handling basics. Think of it like a standardized wiring system for how services talk to each other—critical if we’re building scalable, modular systems. It’s a small dependency (under 1MB) with a permissive license (BSD-3), so it’s low-risk. If we’re investing in event-driven architecture, this is a foundational piece that saves dev time and reduces integration bugs."

For Engineering: *"prooph/common gives us:

• Consistent message structures across services (e.g., Message, Metadata interfaces) to avoid serialization quagmires.
• Interoperability with Prooph’s event-store/service-bus if we adopt those later.
• Battle-tested utilities (e.g., StreamName, MessageFactory) used in production by teams at [prooph’s adopters, e.g., Shopware, etc.]. Tradeoff: Minimal learning curve if you’re familiar with DDD, but not a silver bullet—pair with their event-store for full value. Let’s prototype a single event type first to validate the fit."*