Adding event sourcing to the monolith
In the previous chapter, 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. Those needs were to have them be easy to instantiate, be easy to reference as dependencies, and finally easy to work with in our handlers.
This is what we had before from Chapter 4 in the Refactoring side effects with domain events section:
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...
