In short; because if you have a map you have a context and it gives you situational awareness – without a map to navigate your business, or personal, goals you are probably walking in a dark room with the light of a matchstick – with a map you are walking in the same dark room, but holding a flashlight; giving you the opportunity to be aware of the space you are in. Having situational awareness is a strategic advantage over those who don’t, probably most companies and organization, but more importantly you have the opportunity to actually find new paths or new ways to travel on your map; or how to even redraw the map as you would like it to bee or how the future would look like.
a map gives you situational awareness, making you aware of the space you are in
A real world map example.
Imagine you are going, by car, from Stockholm in Sweden to Helsinki in Finland – you know you need a car, to explore some areas and cities around Helsinki, and to visit a friend in Lahti; about two hours north of the capital.
Without a map and no experience of the route you are likely to depend on asking people on your way there, if you are lucky you get good directions, and don’t have to stop too many times asking for new.
Now, here is a map for you, with the major roads and some water routes plotted. Depending on your needs you could now think of two ways to travel, the first and perhaps most obvious is to go by car around the water (a drive taking about 20-21 hours non stop), the second way would be to go over the water, but then you need a boat, and you must be able to take your car on the boat, but you don’t have access to a boat and are not comfortable with the idea of sailing; the drive of 20 hours seems like the best option.
But, then you meet someone, like me, you show me the map and talk about your travel plans.
me: – ”that sounds like a fun trip, are you going to see anything special up north? Like the polar light or playing golf in Tornio with 11 holes in Sweden and 7 in Finland !? ~I would like to to do that too!” you: ”no, didn’t plan that, I just want to see Helsinki and meet a friend a couple of hours north from there” me: ”I see, but.. why don’t you take the ferry then? you can sleep, eat, relax and even get a SPA treatment if you like while going there, I mean, instead of driving all the way” you: ”Oh.. is there a ferry line? that sound like a better option”
me: ”definitely, and yet another option is to go by air and rent a car, or perhaps your friend has a car to borrow while you are there.” you: ”didn’t think of that, but I’ll take the ferry, it’s definitely the best option for this trip. Thanks!”
Lesson learned: Having a map to show others and talk about makes things super clear
What could the future look like on the map?
Imagine all the things possible and not really possible to explore what might be in a future, near or distant.
Could there be a tunnel under the Baltic Sea? (Östersjön) or a bridge crossing it? Or perhaps the sea could dry out? Or the lands be extended into the sea? Or a massive earthquake could move the countries together?
If you have a map it is easy to start adding layers of ideas and to test concepts in the context of the map.
REMEMBER – on a map, the space has meaning, and you might think of the space as being an obstacle, but know that the obstacle often is the way – ”every obstacle is an opportunity in disguise”
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)