php-ddd icon indicating copy to clipboard operation
php-ddd copied to clipboard

Event Sourcing vs. Event-Driven Architecture (EDA)

Open webdevilopers opened this issue 3 years ago • 0 comments

Since we discovered CQRS and Event Sourcing we almost used it as a silver bullet. No wait - more like an ensurance. We experienced customers re-visiting us asking for features to implement on data that we had because we kept the history of an aggregate. We wanted to be ready for everything the customer would come up with.

But in most of the domains we have aggregates that deal with only a few interesting events e.g. "FooCreated", "FooDeleted" and "FooRenamed".

The latter was the most interesting part. We kept the original names of "Foo" as historical data in other aggregates that referenced it. Just in case somebody wants to know it - mostly in does not happen and everybody wants to see the current name anyway.

At the bottom line we used the "FooRenamed" event across read models of other aggregates. These read models would simply join a "foo_details" table on the database for the current name or use the historic name from the stream.

Each time this process starts again about "stepping back" from event sourcing and go back to event-driven architecture. Mabye an ORM that works for 90% of these "crudish" Foo models. And the most important thing is the Domain Event raised by the Domain Model, send to the event bus and some process manager - done.

What are your thought on this?

For PHP + Doctrine ORM + Symfony Messenger Event Bus scenario please also read: https://github.com/webdevilopers/php-ddd/issues/62

webdevilopers avatar Mar 05 '22 15:03 webdevilopers