CODEWITHSUNDEEP
cqrsevent-sourcing
Ajeo
Ajeo

Reputation: 83

CQRS/Event Sourcing: Should events (types) be shared?

Should events be shared? I am experimenting with CQRS and Event Sourcing and am wondered if events (the types) should be shared/defined between services.

Case:

A request comes in and a new createUser command is pushed into the 'commands' event log. Service A (business logic) fetches this command and generates the data of the new user. Once the new user is created it pushes the new data into the 'events' event log with the event name newUser. Service B (projector) notices the new event and starts processing it.

Here lays my question. Should we define for every event type (in this case newUser) the logics that needs to be ran in order to update the materialised view? In the example below do we have 2 types of events and is for every event the actions defined that need to happen. In this case are the event types defined in the logics service and the projector service.

# <- onEvent
switch event.type
  case "newUser"
  putUsers(firstName=data.firstName, lastName=data.lastName) # put this data in the database

  case "updateUserFirstName"
  updateUsers(where id = 1, firstName=data.firstName)

Or is it a good idea to define in the event the type of operation that needs to be preformed? In that case are event types not shared and is the projector service able to handle unknown/new events, without any modification.

# <- onEvent
switch event.operation
  case "create"
  putUser(...)

  case "update"
  updateUser(...) # update only the data defined in the event

Is options 2 a viable option? Or will I be running into issues when choosing this strategy?

Upvotes: 0

Views: 434

Answers (2)

Sandy
Sandy

Reputation: 1504

I recommend using event type to determine what type of business logic/rules will consume the event.

As @guillaume31 mentioned, use past tense to name your events. But if you want to plan for the future, you should also version your event types. For example, you can name your event types like this "userCreated_v1" or "userFirstNameChanged_v1". This gives you the ability to change the structure of event messages in the future and easily associate new business logic/rules with the new events.

Upvotes: 1

guillaume31
guillaume31

Reputation: 14064

Events reflect something that has happened. They are usually named in the past tense - userCreated.

Generic events (or one event type per entity) have a number of drawbacks:

  • Finding proper past tense names for event types becomes more difficult

  • You lose some of the expressivity since the whole domain meaning is no longer immediately apparent just looking at the event type

  • Impossible to subscribe to events in a fine grained, streamlined way because you need to "open the envelope" to find out which specific event you're dealing with

  • Discrepancy between events you talk about with domain experts (for instance during Event Storming sessions) and the way they are encoded in your types, messages, etc.

I wouldn't recommend it except maybe in a very free-form/dynamic system where the entities are not known in advance.

Upvotes: 1

Related Questions