Domain Driven Design
&
Event Storming
Domain Driven Design
- It’s a technique to design software systems
- It improves communication between stakeholders and development team
- Better understanding of the wider picture
- Helps building modular and maintainable systems
Ubiquitous language
- DDD requires to define a ubiquitous language,
a lingua franca across stakeholders - We build a shared and continuously
updated domain glossary
- This helps domain experts and developers
to use a clear and well-defined language and
minimize risk of misunderstanding
Event Storming
- It’s a process that helps to identify 5 main
parts of the system - events
- roles
- views
- commands
- policies
Event Storming
- Events: these are the most important part and identify what features the system provide and how they work
- Roles: what type of users can use the system
- Views: used by users to take decisions and act
- Commands: operations that the users will perform on the system
-
Policies: business rules that drive specific scenarios
How Event Storming works
- We use a large whiteboard; in our case it’ll be a digital one
- We put virtual post-it notes on the whiteboard
- Each post-it will have a specific color,
based on the type of item identified
how will it look like?
The following are examples of full outcomes
of many Event Storming sessions
Event storming sessions
Event storming sessions
EVENT STORMING SESSIONS
EVENT STORMING SESSIONS
EVENT STORMING SESSIONS
OUR DIGITAL WHITEBOARD
ISN'T THIS MESSY?!
- Yes, it is... and it should be
- The purpose is to brain storm together
- ... and converge the different stakeholders views
LET's GET STARTED
- I hope this will set expectations for tomorrow
- If you like to read something more, this one is a nice overview