Skip to content

Event Sourcing vs. Event-Driven Architecture (EDA) #63

@webdevilopers

Description

@webdevilopers

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:
#62

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions