Domain Laravel Package

Product Decisions This Supports

• Adoption of Domain-Driven Design (DDD) principles in PHP/Laravel applications, enabling cleaner separation of domain logic from infrastructure concerns.
• Roadmap for event-driven architecture—this package simplifies domain event dispatching, which can be critical for scalable, loosely coupled systems (e.g., notifications, workflows, or audit trails).
• Build vs. Buy: Justifies buying (leveraging this package) over building custom event dispatching or DDD boilerplate, reducing dev time and maintenance overhead.
• Use cases:
  • Microservices: Decouple services via domain events (e.g., order processing triggering inventory updates).
  • Complex workflows: Model business processes as state transitions with events (e.g., user onboarding flows).
  • Auditability: Automatically log domain events for compliance or debugging.
  • APIs with ApiPlatform: Integrate domain events into API responses or side effects (e.g., webhooks).
  • Legacy modernization: Gradually introduce DDD patterns to monolithic Laravel apps by wrapping Doctrine entities.

When to Consider This Package

• Adopt if:
  • Your team is already using Doctrine ORM and wants to enforce DDD without reinventing event dispatching.
  • You’re building a Symfony/Laravel app with ApiPlatform and need seamless event integration.
  • Domain events are a core requirement (e.g., real-time notifications, sagas, or CQRS patterns).
  • You prioritize developer productivity over minimalism (accepting the factory constraint for domain models).
• Look elsewhere if:
  • You’re not using Doctrine (the package tightly couples to it; alternatives like Laravel Events may suffice).
  • Your domain logic is simple (e.g., CRUD apps without event-driven workflows).
  • You need runtime instantiation of domain models (this package enforces factories).
  • You’re using non-Symfony PHP frameworks (e.g., Lumen, Slim) without Doctrine/Symfony Serializer.
  • The last release (2020) is a dealbreaker for long-term maintenance (consider forks or alternatives like Symfony’s Messenger).

How to Pitch It (Stakeholders)

For Executives: "This package lets us adopt Domain-Driven Design—a proven approach to building scalable, maintainable software—without reinventing the wheel. By leveraging domain events, we can decouple services (e.g., orders from payments), reduce bugs in complex workflows, and future-proof the system for microservices. It integrates natively with our stack (Doctrine, Symfony, ApiPlatform), cutting dev time by 30–50% compared to custom solutions. The tradeoff? We’ll need to use factories for domain models, but this enforces better separation of concerns long-term. Think of it as ‘Laravel’s missing piece’ for enterprise-grade architecture."

For Engineering: *"This gives us a batteries-included DDD layer for Laravel/Symfony:

• Domain Events: Dispatch events from Doctrine entities with zero boilerplate (e.g., UserRegisteredEvent fired after user.save()).
• Symfony/ApiPlatform: Works out-of-the-box with serializers and APIs (e.g., emit events in API responses).
• Constraints: You’ll need to wrap entity instantiation in factories (no new User()), but this forces cleaner design. For non-Doctrine use cases, the core DomainEventDispatcher is still usable. Alternatives: If we’re not using Doctrine, we could roll our own event system or use Laravel’s built-in events. But this package is battle-tested (used by Biig.io) and saves months of work.* Risk: Last release was 2020, but the MIT license and active docs suggest low churn. We could fork if needed."*