designing events for an event sourcing based application

Question

In an application to handle employee leaves, I decided to try CQRS & event sourcing and came up with the following flow of events.

app events

• leave-application-received
• leave-application-validation-failed
• leave-application-accepted
• leave-applied
• manager-notified
• leave-approved
• leave-rejected
• user-notified
• calendar-updated

from the domain perspective, only applied, approved/rejected are the key events, while other events are more like an application log events.

To implement that in a code, I am making following classes

//command
class ApplyLeave (startDate, numberOfDays) {
    ...
    ...
}

// aggregate root
class EmployeeLeave () {

  handleApplication(leaveApplication) 
  {
    ... code to handle application ...
    ... raise events ...
  } 

}


//event
class LeaveApproved(id, timestamp)
{
} 

Considering this is my first take on cqrs and event sourcing, I am bit worried if I am doing its the right way. my questions are

• should there be events like application-received which is just a log of http request received? I think it has no meaning in domain, so it should not be recorded, but on the other hand, if a request failed half way, knowing that a request was received might be useful?
• if having app events like application-received is ok, should I create two event stores? domain-events and app-events?

I might be completely off the track, because I read a lot of articles but didn't find any sample code on how to actually implement cqrs+es.

Answer 1

High level: when we are talking about event sourcing, what we are really talking about is describing the state of your domain model using non-destructive edits.

Event sourcing doesn't change the information you track with the domain model, it only changes the data structures that we use to keep track of that information.

So what information do we keep? As a rule, we only keep the information that we are going to need to answer a question later, which is to say either (a) information that will be emitting in response to a query OR (b) information that is going to feed back into future "decisions" / state changes made by this model.

Metrics/observability information is typically neither of these, therefore we don't consider it to be part of the domain model's "state", therefore we don't include that information in the data structure that describes the model's state. In other words, we restrict the domain model to storing information that relates to domain concerns.

Information that supports application concerns is usually written "somewhere else": in counters used for publishing metrics, written out to logs so that you can apply your observability toolkit to it, and so on.

Are you allowed to put the application information into the domain model's history? Of course - if you are willing to accept the trade offs that come with that. It's not all that different from writing a bunch of "NothingHappened" events into you history. But you may find when you look into it that the value of having that information coupled to your domain information does not offset the costs (additional contention being perhaps the most obvious of these).