When looking at this video walk-through of OAuth Event Modeling in Go by Jamie there was a question about how to handle commands without the need of switches over the command types.
So my reply on that got a little longer and thought I would share the resources I pointed to here (to free the comment from being stuck in youtube)
Great example and walk through Jamie! (and thanks to the rest of you for value provided)
Regarding handling events without the switch, I do not know Go – but in C# you usually register EventHandlers with commands and you will have a dispatcher or similar as a single entry point where the handlers knows what commands they should act on. see examples in referred links below.
So, maybe this is not for Go devs, but you might get some ideas from it, anyhow.. here are some links for c# resources.
”This repository shows how to implement Event Sourcing, CQRS and DDD in .NET Core, using a Bank as example.”
I like to look at things in the order of ”from entry point in the API”, Hope you can follow my logic =)
Command to Result flow.
start in ’Api\Controllers\StudentController.cs’.Register(…)
//called from UI to register student
var command = new RegisterCommand(...); // (Logic\AppServices\RegisterCommand.cs)
Result result = _messages.Dispatch(command); //finds handler, handles the command and returns the result.
The message Dispatcher
in ’Messages.Dispatch(command)’ the matching handler for the command is looked up, via DI, and then executed (aka handled).
handler = _provider.GetService(handlerType); // System.IServiceProvider (built in)
result = handler.Handle(command);
The Registration of handlers
DI, Dependency Injection, is configured in ’API\Startup.cs’ and handlers, for commands and queries; these are registered via services.AddHandlers() – where ’services’ is ’Microsoft.Extensions.DependencyInjection’
This class takes care of finding, and registering, all handlers of type ICommandHandler and IQueryHandler in the assembly,
making them available for use from IServiceProvider.GetService(serviceType)
Brick by brick, piece by piece, part by part – anything an object? anything an event?
What if.. you did lay out the bricks in a good way, to support the small house you started to build, but then decided you should widen your house, or perhaps make it taller, and just started over – brick by brick. This might be hard, probably to expensive, but possible, in the brick house world. Sure, some of the events bricks might be broken and, thrown away, replaced by new ones.
In the software world it often gets to messy and expensive, but can many times be a lot easier than in the physical world. Since we, in an event sourced system, could tear down the brick wall (our UI data projection), and replace all bricks (i.e. events) in the places we want them for our new building.
I have a simple challenge for you
Think of anything in the world and try to convince me it is not a result of events from the past.
So, last week I restarted my learning path of event sourcing and eventstore, and today I happened to stumble on this post https://eventstore.com/blog/event-sourcing-and-cqrs/ by @AlexeyZimarev – I can highly recommend it as an introductory article on event sourcing and cqrs (pointing at eventstore with some examples) + DDD talks from Alexey.
I was not about to write an article but since I had to much text for a simple post on LinkedIn I expanded 🤠
I’m familiar with the concept of event sourcing and believe most systems should use it, but haven’t worked with it for 3 years and wasn’t fluent then; now I need to learn it solidly for a personal project and also to evolve as a software developer.
Why event sourcing? What is it good for? You want the truth?(Pi)
If you are a developer and not familiar with event sourcing you should update yourself.
a 6 minute answer of why event sourcing by Alexey – in short; it enables you to know what has happened in the past which enables troubleshooting and capitalization of user behavior etc, the historical data is not destroyed as in a ”state managed system”, i.e. traditional CRUD, and thus you always have the truth.
The power of events is unlimited compared to traditional crud systems.
Events are not new in the software world, but for a long time too many systems have suffered from not having an event based implementation.
Your bank account transaction history is perhaps the most publicly known example of event sourcing – all historical events builds the current balance (history is complete).
From a technical perspective
maintenance and support in state managed vs event sourced systems.
Troubleshooting and support in a STATE managed system.
In the development phase when defects are found and no one knows what happened and the original data is overwritten by the defect but you don’t know it did – it gets hard to find the issue. Or worse, the defect gets shipped and destroys data at a customers site and you can’t restore the data, you can’t see if the system caused it or if the customer has changed the data.
Support – without the possibility to see what happened, in the system before it got to a ”broken” state, it takes a lot of effort to track what has changed and by who, and users might not know or remember, or don’t dare to tell the truth. If you have great logging in place, you might be able to track changes that way – but it’s often not efficient, if at all possible.
Troubleshooting and support in an EVENT sourced system
Troubleshooting in development and support; since you have access to all events, you can look at all events in the time between a last known good state and the broken state, you can see what really did happen, and what or who caused it, and when.
For difficult support cases it becomes possible to take a database from a production system in a broken state, replay all events (i.e. rebuilding the state from history) and observe what happens – just like following a rope from end to end, instead of wrestling in a big ball of mud or looking for a needle in a hay stack.
Aligned with the real world languages and human thinking
Perhaps the greatest power is that events are natural for our minds, and something I could talk to my mum about(she doesn’t really understand what I mean when I say web browser).
Stories are made of events
as am I, so are You, as are the history of life
Humans are exceptionally good at remembering stories, stories are made of events, as am I, so are You, as are the history of life.
So, talking with users, domain experts, developers etc. becomes easier – developers can learn the actual business process and language much faster and actually talk to non technical people (at least some.. I can 😉) about what is going on in the code.
Product and business life cycle – room for evolving and improving together.
Projected read models, f ex for display to users or other systems, becomes easy to alter and make variations of as the system grows and business evolves, as the business thinks of new concepts.
Adding new types of events and letting other systems listen to event changes gets easy.
Business intelligence (i.e. tracking what happened and when) becomes easy, having insight in how customers and the user behaves is very valuable for improving the software and the business drivers. Storing the source of truth enables business to reuse the data in not yet known ways.
Getting new team members up to speed on how the system behaves is easier when events can be lined up in an overview.
Combine event storming, to understand the important things of the domain in collaboration of domain experts and software developers, with domain story telling, to find important concepts, use cases and user interactions/flows; and then map them to an eventmodeling system blueprint – readable by most people (at least with a brief explanation)
And now ”all” you need to do is to build the software (using TDD and DDD in a mobprogramming team – IMHO)