Most scaling discussions about event-sourced projections start with resources.
To me, they should start with the projecting model itself.
If the design doesn't allow scaling, hardware doesn't move the wall.
Wrote up the model we applied in Ecotone. Article already available for free members of https://t.co/tU3VrJTMis
https://t.co/HLxVTHvoF0
Most projection articles talk about the happy path.
But that is usually not where teams struggle.
They struggle:
- When a projection crashes on one bad event.
- When a read model bug blocks a valid business operation.
- When catch-up runs eat memory and lock tables for too long.
And when recovery means manual resets, replay scripts, and stress at 3 AM.
"Your Projection Will Fail" article is about those problems. I wrote it to show how resilient projections should actually work:
- How to isolate projection failures from the command side
- How to make projections self-heal after a fix
- How protects you from memory and transaction issues
So if you have ever dealt with projections that were fragile, blocking, or painful to recover, this is for you.
Your projections will fail.
The real question is what happens next.
Do they recover after a fix?
Do they block valid business operations?
Do they turn catch-up into operational pain?
Thatโs what this article is about.
Available now on https://t.co/tU3VrJTMis with a free account.
Public release on Tuesday.
#php #ddd #eventsourcing #cqrs
Jean (main co-maintainer) and I have been rebuilding the Event Projecting System in Ecotone from scratch โ replacing the Prooph-based engine.
Today it's public, along with a 5-part article series:
โ Track-based gap detection (no more silent data loss)
โ Self-healing projections
โ Partitioned scaling
โ Event emission from read models
โ Blue-green deployments
I've written one article per topic, new one every week starting today. The articles go deep on internals and patterns โ useful whether you use Ecotone or not.
โ Article 1 is live on https://t.co/tU3VrJUk80. New one every week. Register on the platform for free - to get the next article early.
"Commands belong to the Application Layer" is the most repeated DDD rule that nobody stops to question.
Let's think about it differently.
Commands are actions we want to perform. Events are results of actions taken. Two sides of the same pipe. Events follow business language ("OrderWasPlaced") โ so why don't Commands? "PlaceOrder" IS business language. It IS a domain concept.
Now remember what Alan Kay meant by OOP: all communication happens through Messages. Commands are Messages. Aggregates are transaction boundaries โ our entrypoints.
If communication happens through Messages, and Aggregates are entrypoints... Command Handlers are just business actions on Aggregates. They map 1:1.
So why do we write 50 identical handler classes that all do: load aggregate, call method, save, publish events?
That's not application logic. That's infrastructure. The framework should own it.
With Ecotone:
```php
#[Aggregate]
class Order
{
#[CommandHandler]
public static function create(CreateOrder $command): self
{
// just business logic here
}
}
```
No Application Layer. No handler classes. The Command maps directly from HTTP โ no Request -> DTO -> Command chain. No re-mapping means no problems.
To add new business logic: method on Aggregate + Controller action. Done. Simpler than CRUD.
The problem was never DDD. It was treating guidelines as laws and building ceremony instead of business logic.