//sumtype:decl
type AccountEvent interface {
event.Any
isAccountEvent()
}
//...
return a.recordThat(&moneyDeposited{
Amount: amount,
})
I am in favor of discoverable APIs that leverage simple IDE features, like string completion. The API that I would design for recording events would be closer to:
return a.event.AccountDeposit(amount)
And when you do it this way, you no longer need to pull in the the non-standard sum types package that requires comment annotations and subsequent linting packages.
I suppose the goal here is a general framework so to make things general, you are adding indirection. I've not had to create new events in an event sourced architecture on a regular cadence. Usually, any particular team has N events they generate, where N is relatively small and almost never gets new events. And my events are usually historic or log-like in nature, spreading data out to other systems and the events themselves are not the source of truth, but the system that generated them is
You're not forced to use that comment, you can pass the event however you like, if you satisfy the event.Any interface (by having the method EventName() string).
I prefer that comment because Go doesn't have native sum types, and I believe that by using the framework in combination with the gochecksumtype linter, you get the best developer experience and type safety (you DO have tab autocomplete with the events for recordThat - the type system helps because of the sealed interface).
But again, if you don't want to use the linter, no problem. You can create constructors for the events however you like, just like in your example.
Just FYI - There's a pretty popular (in finance circles) JVM library called Chronicle[0], which also deals with high throughput event queues etc.