From EventStorming to CoDDDing @Javaland

To really understand what our users need so that we can build the right thing, we want to have a first-hand experience of 'real-life stories' before we model and create our software. To quote Alberto Brandolini "it is not the domain expert's knowledge that goes into production, it is the developer's assumption of that knowledge that goes into production". EventStorming is a visual technique that minimizes assumptions by engaging in collaborative deliberate learning across different disciplines. This helps to solve complex business problems in the most effective way.

Although the learning of the domain helps us to understand the domain better, EventStorming can be quite an overwhelming experience. Developers can be left with the question of how to turn a few stickies on a wall into working code.

Join us in this talk in which we show the basic principles of EventStorming. We will cover the different forms of EventStorming and in which situation they best can be applied. And, we will show how you can leverage DDD (Domain-Driven Design) patterns in an EventStorming software modelling session that will ultimately result in coding TDD (Test Driven Development) style!

Transcript

1. From EventStorming to CoDDDing
2. 2 Strategic Technology Consultants - Agile Technical Coaches - Domain-Driven Design - Continuous Delivery - EventStorming - Example Mapping @kenny_baas baasie.com @joaoasrosa joaorosa.io
4. 4 @kenny_baas @joaoasrosa
7. 7 The fundamental horror of this anti-pattern is that it's so contrary to the basic idea of object-oriented designing; which is to combine data and process together. - Martin Fowler @kenny_baas @joaoasrosa
8. 8 What's worse, many people think that anemic objects are real objects, and thus completely miss the point of what object-oriented design is all about. - Martin Fowler @kenny_baas @joaoasrosa
9. 9 @kenny_baas @joaoasrosa
10. 10 @kenny_baas @joaoasrosa
11. We all know or should know that language is fluid, liquid, subject to the whims of the people. Language evolves, as it should. Because language changes to accommodate new users, the older users resist and complain. http://tednellen.blogspot.com/2013/04/language-is-fluid.html
16. 16 @kenny_baas @joaoasrosa
17. 17 Confirmation Bias @kenny_baas @joaoasrosa
18. 18 @kenny_baas @joaoasrosa
19. 19 It is not the domain experts knowledge that goes to production, it is the assumption of the developers that goes to production - Alberto Brandolini @kenny_baas @joaoasrosa
20. 20 @kenny_baas @joaoasrosa
21. 21 The greatest obstacle to discovery is not ignorance - it is the illusion of knowledge. - Daniel J. Boorstin @kenny_baas @joaoasrosa
22. 22 @kenny_baas @joaoasrosa
25. 25 Big Picture Process Design and Modelling Software Modelling @kenny_baas @joaoasrosa
26. 26 @kenny_baas @joaoasrosa
27. 27 @kenny_baas @joaoasrosa
28. 28 @kenny_baas @joaoasrosa
31. 31 Source: https://medium.freecodecamp.org/coding-explained-in-25-profound-comics-8847ea03819c @kenny_baas @joaoasrosa
32. 32 Source: https://nl.pinterest.com/pin/550846598149452758/ @kenny_baas @joaoasrosa
33. 33 Source:https://www.dw.com/en/maligned-ronaldo-statue-replaced-at-madeira-airport/a-44279114 @kenny_baas @joaoasrosa
34. 34 Solution Space Our world as we designed it Bounded Context Software Architecture Linked to the business Problem Space Our world as we perceive it (Sub)Domains Business Architecture Independent of Software @kenny_baas @joaoasrosa
35. 35 @kenny_baas @joaoasrosa
36. 36 A model is a simplified representation of a thing or phenomenon that intentionally emphasizes certain aspects while ignoring others. Abstraction with a specific use in mind. @kenny_baas @joaoasrosa
37. 37 @kenny_baas @joaoasrosa
38. 38 @kenny_baas @joaoasrosa https://blog.ncrunch.net/post/london-tdd-vs-detroit-tdd.aspx
40. 40 Source: https://nl.pinterest.com/pin/550846598149452758/ @kenny_baas @joaoasrosa 1. Write a coarse-grain test a. Outside-in testing 2. Start with entrypoint of our model 3. Design-by-Coding 4. Assess if the models can easily evolve to support other features
41. 41 @kenny_baas @joaoasrosa
42. 42 1. Protects business invariants 2. Design them small 3. Reference other by ID only 4. Update other using eventual consistency @kenny_baas @joaoasrosa
43. 43 @kenny_baas @joaoasrosa Source: https://unsplash.com/photos/eYZpTMc7hno Domain logic that doesn’t belong to a - Entity - Value Object Significant process or transformation that concerns the domain logic Isolate in a standalone interface declared as a service Part of the ubiquitous language
44. 44 @kenny_baas @joaoasrosa
45. 45 Source: http://www.mamuz.de/article/from-big-ball-of-mud-to-emergent-design/0Pw682Kxk @kenny_baas @joaoasrosa
47. 47 Source: http://www.mamuz.de/article/from-big-ball-of-mud-to-emergent-design/0Pw682Kxk @kenny_baas @joaoasrosa 1. Visualise a. Business information flow b. Behaviour of the system 2. Protect domain logic with tests a. Inside-out b. Outside-in 3. Experiment models to fit the behaviour a. Ubiquitous language will emerge 4. Protect models with Bounded Contexts
48. 48 @kenny_baas @joaoasrosa
49. 49 Software Development is a learning process, working code is a side effect. - Alberto Brandolini @kenny_baas @joaoasrosa
50. 50 Try at least to find three models, even if you think you already found the “right model” @kenny_baas @joaoasrosa
51. 51 Serious software development is the practice of symmathesy. “Sym” = together, “mathesy” = learning. - Jessica Kerr @kenny_baas @joaoasrosa
52. #CatTax