Event-Driven Architecture in Golang/

...

/

Adding Event Sourcing to the Monolith

Adding Event Sourcing to the Monolith

Explore enriching our events and aggregates to support event sourcing.

We'll cover the following...

We added a domain-driven design package for the monolith to use called ddd. We will need to make some updates to this package and add a new one for our event sourcing needs.

Beyond basic events

The event code we used before was just what we needed. The needs specified were to make them straightforward to instantiate, convenient to reference as dependencies, and finally, easy to work with in our handlers.

type EventHandler func(ctx context.Context, event Event) error
type Event interface {
    EventName() string
}

This old Event interface required that the plain old Go structs (POGSs) that we are using implement the EventName() method to be seen by the application as an Event.

Refactoring toward richer events

We have the following new needs:

  • We need to know the details of which aggregate the event originates from.

  • Events need to be serialized and deserialized so they can be written and read back out of the database.

With these new needs in mind, we need to revisit the events code in the ddd package and make some updates. The new interface for our event is shown in the following ...