This API requires that you know what you can pass into it - not a type, an interface. You know, by way of being familiar with the code base, you have moneyDeposited that matches. Do you have userSuspended wired up? Is that even an option? As your code base grows and as new developers onboard, more and more of the events available will become need to take up mental space.
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)
What other events can you record? Just tab away and find out. AccountSuspend pops right up.
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.
Do you have some of your cases documented somewhere? Would love to take a look at it, since I'm working at an enterprise that has extensive Kafka support and adoption, but event sourcing is not widely used so far. I'm afraid to start championing event sourcing as a way to keep our systems integrated with less cognitive overhead and redundancy, but end up falling into a trap.
This is a lot of work to make the following work and it feels odd to force comments onto my structs to make your API able to look like the following:
This API requires that you know what you can pass into it - not a type, an interface. You know, by way of being familiar with the code base, you have moneyDeposited that matches. Do you have userSuspended wired up? Is that even an option? As your code base grows and as new developers onboard, more and more of the events available will become need to take up mental space.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:
What other events can you record? Just tab away and find out. AccountSuspend pops right up.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
Hey, author here
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.
Do you have some of your cases documented somewhere? Would love to take a look at it, since I'm working at an enterprise that has extensive Kafka support and adoption, but event sourcing is not widely used so far. I'm afraid to start championing event sourcing as a way to keep our systems integrated with less cognitive overhead and redundancy, but end up falling into a trap.
Hey! Congrats on shipping.
Just FYI - There's a pretty popular (in finance circles) JVM library called Chronicle[0], which also deals with high throughput event queues etc.
[0]: https://chronicle.software/
Hi, author here
I wasn't aware of this library, I did check for name collisions with other Go repos though
Not sure why this was downvoted, I found the terminology confusing and wondered if there was overlap with Chronicle Software myself.
May I ask, idiomatic by what standard?