Event-Driven Architecture (EDA) focuses on decoupling systems and making them more flexible, scalable, and maintainable by responding to events. In PHP, two important patterns that are often used in EDA are Event Sourcing and Command Query Responsibility Segregation (CQRS). Here’s a step-by-step guide to implementing them using PHP, along with a hands-on example.
Concepts Overview
1. Event Sourcing:
- Instead of persisting just the final state of the application in the database, every change (event) to the application state is stored.
- Example: If you have an order system, instead of storing only the latest order status, you store every action on the order like "Order Created", "Item Added", "Order Paid", etc.
2. CQRS:
- CQRS separates read (query) and write (command) operations. The two models may evolve separately, with the write model focusing on business logic and validation, and the read model on data representation.
- Example: For a complex system like an e-commerce site, the logic to place an order (write) could be separated from fetching the order details (read).
Architecture Flow
-
Command:
- A command is an action that requests a change in state (e.g., "PlaceOrder", "AddItemToOrder").
- The command is handled by a Command Handler that performs business logic and emits events.
-
Event:
- After a command is processed, an event (e.g., "OrderPlaced", "ItemAdded") is raised, representing that something important has happened.
- Events are immutable, and they trigger actions in other parts of the system, such as updating read models or notifying external systems.
-
Read Model:
- The read model is kept up-to-date by reacting to events. It is optimized for read operations and might have a different schema than the write model.
Step-by-Step Example: An Order System
Step 1: Setting Up Project
Create a directory structure:
event-driven-php/
├── src/
│ ├── Commands/
│ ├── Events/
│ ├── Handlers/
│ ├── Models/
│ └── ReadModels/
├── tests/
└── vendor/
Install dependencies (e.g., symfony/event-dispatcher):
composer require symfony/event-dispatcher
Step 2: Define Commands
Commands represent actions that change the state. Example: PlaceOrderCommand.php.
// src/Commands/PlaceOrderCommand.php
class PlaceOrderCommand
{
public string $orderId;
public string $customerId;
public function __construct(string $orderId, string $customerId)
{
$this->orderId = $orderId;
$this->customerId = $customerId;
}
}
Step 3: Create Events
Events describe what happened in the system. Example: OrderPlacedEvent.php.
// src/Events/OrderPlacedEvent.php
class OrderPlacedEvent
{
public string $orderId;
public string $customerId;
public function __construct(string $orderId, string $customerId)
{
$this->orderId = $orderId;
$this->customerId = $customerId;
}
}
Step 4: Command Handlers
Command handlers perform the actual business logic and raise events. Example: PlaceOrderHandler.php.
// src/Handlers/PlaceOrderHandler.php
use Symfony\Component\EventDispatcher\EventDispatcher;
class PlaceOrderHandler
{
private EventDispatcher $eventDispatcher;
public function __construct(EventDispatcher $eventDispatcher)
{
$this->eventDispatcher = $eventDispatcher;
}
public function handle(PlaceOrderCommand $command)
{
// Business logic (e.g., check stock, validate order)
// Emit the event
$event = new OrderPlacedEvent($command->orderId, $command->customerId);
$this->eventDispatcher->dispatch($event, 'order.placed');
}
}
Step 5: Event Handlers (Projecting Data to Read Models)
An event handler listens for specific events and updates the read model. Example: OrderProjection.php.
// src/ReadModels/OrderProjection.php
class OrderProjection
{
private array $orders = [];
public function onOrderPlaced(OrderPlacedEvent $event)
{
// Save or update read model with necessary data
$this->orders[$event->orderId] = [
'orderId' => $event->orderId,
'customerId' => $event->customerId,
'status' => 'placed'
];
}
public function getOrder(string $orderId)
{
return $this->orders[$orderId] ?? null;
}
}
Step 6: Putting It Together
use Symfony\Component\EventDispatcher\EventDispatcher;
// Bootstrapping the system
$dispatcher = new EventDispatcher();
$orderProjection = new OrderProjection();
// Register event listeners
$dispatcher->addListener('order.placed', [$orderProjection, 'onOrderPlaced']);
// Create the command and command handler
$command = new PlaceOrderCommand('123', 'cust_001');
$handler = new PlaceOrderHandler($dispatcher);
// Handle the command (Place the order)
$handler->handle($command);
// Query the read model for the order
$order = $orderProjection->getOrder('123');
print_r($order);
Output:
Array
(
[orderId] => 123
[customerId] => cust_001
[status] => placed
)
Step 7: Event Store (Optional)
For full event sourcing, you'd also implement an event store to persist events to a database.
class EventStore
{
private array $storedEvents = [];
public function append(Event $event)
{
$this->storedEvents[] = $event;
}
public function getEventsForAggregate(string $aggregateId): array
{
return array_filter($this->storedEvents, function($event) use ($aggregateId) {
return $event->aggregateId === $aggregateId;
});
}
}
Part-by-Part Breakdown
- Command Creation: Represents the user's intent to change something.
- Command Handling: Business logic that processes commands and raises events.
- Event Emission: Events raised after commands are successfully handled.
- Event Handling: Projects the event data into read models for optimized querying.
- CQRS Separation: The command model focuses on domain logic, while the query model is optimized for fast lookups.
- Event Store: Optionally, persist events to replay state when needed.
Conclusion
This example demonstrates a simple application of CQRS and Event Sourcing in PHP. With these patterns, you can build systems that scale well and are maintainable, while providing powerful auditability and flexible read/write handling. The architecture can grow with additional projections, more complex event handling, and external integrations like messaging queues or third-party notifications.
Top comments (0)