From EventStorming to CoDDDing @ DDD Taiwan

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". Visual collaboration are tools that minimize 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, visual collaboration tools like EventStorming and Example Mapping can be quite an overwhelming experience. Developers can be left with the question of how to turn a few stickies or index cards into working code.

Join us in this talk where we will leverage Eric Evans model exploration whirlpool. We will show how to create a shared mindset by telling a story with visual collaboration tools like EventStorming and Example Mapping. From there start to propose models by leveraging Domain-Driven Design patterns. We end up going from our model to code probe by doing outside in Test Driven Development! You will leave with the knowledge to go from visual collaborate modelling to coding while refining your ubiquitous language.

Transcript

1. @kenny_baas @joaoasrosa From EventStorming to CoDDDing
2. 2 Strategic software delivery - Domain-Driven Design - Continuous Delivery - Socio-technical engineers - Collaborative modellers and facilitators @kenny_baas baasie.com @joaoasrosa joaorosa.io
3. @kenny_baas @joaoasrosa
4. @kenny_baas @joaoasrosa
5. @kenny_baas @joaoasrosa Using models for creating software
6. @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. @kenny_baas @joaoasrosa Shared language created through conversations between business people (specialists) and software people which becomes the ubiquitous language
12. 12 @kenny_baas @joaoasrosa
13. 13 @kenny_baas @joaoasrosa
14. @kenny_baas @joaoasrosa
15. @kenny_baas @joaoasrosa
16. @kenny_baas @joaoasrosa
17. 17 “That shallowness of knowledge produces software that does a basic job but lacks a deep connection to the domain expert’s way of thinking.” - Eric Evans @kenny_baas @joaoasrosa
18. @kenny_baas @joaoasrosa Focus on a language where we really crisply concisely describe the situation in the domain
19. @kenny_baas @joaoasrosa
20. 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 @kenny_baas @joaoasrosa
21. @kenny_baas @joaoasrosa Instead of one canonical language, create multiple bounded languages
22. 22 @kenny_baas @joaoasrosa
23. “A loosely coupled software architecture and org structure to match” is a key predictor of: 1. Continuous Delivery Performance 2. Ability to scale org and increase performance linearly Credits: Nick Tune @kenny_baas @joaoasrosa
24. @kenny_baas @joaoasrosa Focus on part of the software handling complex business requirements
25. @kenny_baas @joaoasrosa Photo by Product School on Unsplash
26. 26 @kenny_baas @joaoasrosa
27. 27 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
28. @kenny_baas @joaoasrosa
29. 29 Big Picture Business process modelling Software design @kenny_baas @joaoasrosa
30. 30 @kenny_baas @joaoasrosa Credits: EventStorming.com
31. 31 @kenny_baas @joaoasrosa
32. 32 @kenny_baas @joaoasrosa
33. @kenny_baas @joaoasrosa
34. @kenny_baas @joaoasrosa
35. 35 Source: https://medium.freecodecamp.org/coding-explained-in-25-profound-comics-8847ea03819c @kenny_baas @joaoasrosa
36. 36 Source: https://nl.pinterest.com/pin/550846598149452758/ @kenny_baas @joaoasrosa
37. 37 Source:https://www.dw.com/en/maligned-ronaldo-statue-replaced-at-madeira-airport/a-44279114 @kenny_baas @joaoasrosa
38. 38 @kenny_baas @joaoasrosa
39. 39 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
40. 40 @kenny_baas @joaoasrosa
41. 41 Business @kenny_baas @joaoasrosa
42. 42 Business Architects @kenny_baas @joaoasrosa
43. 43 Business Architects Developers @kenny_baas @joaoasrosa
44. 44 Business Architects Developers @kenny_baas @joaoasrosa
45. 45 https://domainlanguage.com @kenny_baas @joaoasrosa
46. @kenny_baas @joaoasrosa
47. 47 Try at least to find three models, even if you think you already found the “right model” @kenny_baas @joaoasrosa
48. 48 https://domainlanguage.com @kenny_baas @joaoasrosa
49. 49 @kenny_baas @joaoasrosa https://blog.ncrunch.net/post/london-tdd-vs-detroit-tdd.aspx
50. @kenny_baas @joaoasrosa
51. 51 Source: https://nl.pinterest.com/pin/550846598149452758/ @kenny_baas @joaoasrosa 1. Write a coarse-grain acceptance 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
52. 52 @kenny_baas @joaoasrosa
53. 53 1. Protects business invariants 2. Design them small 3. Reference other by ID only 4. Update other aggregates using eventual consistency @kenny_baas @joaoasrosa
54. @kenny_baas @joaoasrosa
55. 55 https://domainlanguage.com @kenny_baas @joaoasrosa
56. 56 Essence of Domain-Driven Design ➔ Using models for creating software ➔ Focus on part of the software handling complex business requirements ➔ Focus on a language where we really crisply concisely describe the situation in the domain ➔ Shared language created through conversations between business people (specialists) and software people which becomes the ubiquitous language ➔ Instead of one canonical language, create multiple bounded languages
57. 57 Software Development is a learning process, working code is a side effect. - Alberto Brandolini @kenny_baas @joaoasrosa
58. 58 Serious software development is the practice of symmathesy. “Sym” = together, “mathesy” = learning. - Jessica Kerr @kenny_baas @joaoasrosa
59. @kenny_baas @joaoasrosa Virtual Domain-Driven Design https://virtualddd.com
60. #CatTax @kenny_baas @joaoasrosa https://github.com/xebia/CoDDDing-labs