Using Event Storming and DDD to prototype (micro)services and NFRs - 2
With Event Storming and DDD, we can draft services boundaries and NFR prototypes. In this post sequel, we’ll see that microservices are no silver bullet.
The previous post presented an Event Storming follow-up activity to draft service boundaries. If you haven’t yet, read this post first.
This is also the 16th post in a series about how to use Event Storming to kick start architecture on good tracks. It all started with misadventures with Big Design Up Front.
By itself, the previous post presented all there is to know to run the workshop activity. Before going over tips and warnings, let’s first list the outcomes at this point.
Outcomes
With only 1 or 2 extra hours on top of Event Storming, we should have an idea of what our target services could be. Here are the benefits (quite like that of other Event Storming activities):
- Collective buy-in in a target architecture. Everyone will take more coherent decisions in their day to day work. For example:
- When developers will refactor, they’ll all do so in the same direction of the target architecture
- Developers will keep code modules in line with the target services and boundaries
- Short-term actions. The pink post-its: quick wins, show-stoppers and prototypes to reduce risks or fail fast
- All this in less than a week. Traditional architecture discussions typically span over months. In comparison, Event Storming is a short, but focused, time investment.
💡 Traditional architecture discussions typically span over months. In comparison, Event Storming is a short, but focused, time investment.
Don’t jump into micro-services!
A word of warning ⚠️: do not jump into micro-services. Even though everyone is talking about them, micro-services are no silver-bullet. They do solve tricky organization problems in large scale teams. They also bring their own set of problems:
- They are a headache to operate
- They tend to be more difficult to refactor
- Maintaining consistency across services is incredibly more difficult
- They create the risk for technology silos
Think of alternatives before jumping in micro-services:
- Simple modular code
- Start more instances of your monolith, and synchronize data through your databases
- A few services or processes (not micro) might be all you need
- Use the same code with different entry points. It’s an easy way to reuse the same business domain logic in different processes
- Simple Publish-Subscribe event bus might be good enough right now
For french speakers, Arnaud Lemaire gave an interesting talk on the topic a Paris DDD meetup.
As always, software a matter of tradeoffs, and there is no one size-fits-all solution. You might very well start with modular code and keep your code “micro-service ready”. The day you really need micro-services, you’ll be ready to jump in!
Tips
Here are 3 tips to make this more effective.
Repeat
This is a general Event Storming tip. It’s good to regularly re-do the exercise to update the picture and vision. It’s faster every time a team repeats it.
Design Level Event Storming
We could also try to do Design-Level Event Storming. Going into finer-grained design will clarify the messages exchanged between services. Here is a follow-up series about Design-Level Event Storming.
Evolutionary design
Use evolutionary design and architecture techniques to transform these designs into real software. Building the target architecture up-front is a waste of time. Spend some time practicing and mastering these techniques if you don’t yet do. It might be time to start a coding dojo!
💡 Start a coding dojo to transform Event Storming and DDD into evolutionary architecture and emergent design
Just do it
Event Storming is a bit like paper prototyping for software design and architecture. It makes it possible to do, in a few days of workshops, what is usually done in months of architecture and planning. Learn more about how to get started here. It’s a lot easier to try than you might think.
This was the 16th post in a series about how to use Event Storming to kick start architecture on good tracks. The next post will be about a follow-up workshop to get insights whether to rewrite or refactor.
Leave a comment