(3 related links, aligning on a purpose of joyful life and work)
I just read this highly Recommended article, with a team exercise, by Viktor Cessan, on how to help the individual team members (you included), achieving and finding direction for their personal growth by including the whole team in the discovery process. Also aiming to make the team and organization evolve.
The missing dimension in the traditional approach is team’s context i.e. its challenges, growth areas, and goals (short and long term). Teams that seriously consider and let those aspects influence individual goals, outperform teams that define individual goals in isolation of context.
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)