CODEWITHSUNDEEP
aggregatedomain-driven-designevent-sourcingdomain-events
Mehdi FarokhTabar
Mehdi FarokhTabar

Reputation: 67

version of aggregate event sourcing


According to event sourcing. When a command is called, all events of a domain have to be stored.
Per event, system must increase the version of an aggregate. My eventstore is something like this:

(AggregateId, AggregateVersion, Sequence, Data, EventName, CreatedDate)
(AggregateId, AggregateVersion) is key

In some cases it does not make sense to increase the version of an aggregate. For example, a command register an user and raises RegisteredUser, WelcomeEmailEvent, GiftCardEvent.

how can I handle this problem?

Upvotes: 0

Views: 234

Answers (2)

Roman Eremin
Roman Eremin

Reputation: 1451

Event changes the state of an aggregate, and therefore changes its version. If state is not changed, then there should be no event for this aggregate.

In your example, I would ask myself - if WelcomeEmailEvent does not change the state of the User aggregate, then whose state it chages? Perhaps some other aggregate - some EmailNotification service that cares about successful or filed email attempt. In this case I would make it event of those aggregate which state it changes. And it will affect version of that aggregate.

Upvotes: 1

VoiceOfUnreason
VoiceOfUnreason

Reputation: 57257

how can I handle this problem?

Avoid confusing your representation-of-information-changes events from your publishing-for-use-elsewhere events.

"Event sourcing", as commonly understood in the domain-drive-design and cqrs space, is a kind of data model. We're talking specifically about the messages an aggregate sends to its future self that describe its own changes over time.

It's "just" another way of storing the state of the aggregate, same as we would do if we were storing information in a relational database, or a document store, etc.

Messages that we are going to send to other components and then forget about don't need to have events in the event stream.

In some cases, there can be confusion when we haven't recognized that there are multiple different processes at work.

A requirement like "when a new user is registered, we should send them a welcome email" is not necessarily part of the registration process; it might instead be an independent process that is triggered by the appearance of a RegisteredUser event. The information that you need to save for the SendEmail process would be "somewhere else" - outside of the Users event history.

Upvotes: 2

Related Questions