Upgrade to Pro — share decks privately, control downloads, hide ads and more …

From EventStorming to CoDDDing @ DDD Taiwan

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.

Kenny Baas-Schwegler

November 27, 2020
Tweet

More Decks by Kenny Baas-Schwegler

Other Decks in Programming

Transcript

  1. 2 Strategic software delivery - Domain-Driven Design - Continuous Delivery

    - Socio-technical engineers - Collaborative modellers and facilitators @kenny_baas baasie.com @joaoasrosa joaorosa.io
  2. 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
  3. 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
  4. @kenny_baas @joaoasrosa Shared language created through conversations between business people

    (specialists) and software people which becomes the ubiquitous language
  5. 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
  6. @kenny_baas @joaoasrosa Focus on a language where we really crisply

    concisely describe the situation in the domain
  7. 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
  8. “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
  9. 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
  10. 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
  11. 47 Try at least to find three models, even if

    you think you already found the “right model” @kenny_baas @joaoasrosa
  12. 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
  13. 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
  14. 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
  15. 57 Software Development is a learning process, working code is

    a side effect. - Alberto Brandolini @kenny_baas @joaoasrosa
  16. 58 Serious software development is the practice of symmathesy. “Sym”

    = together, “mathesy” = learning. - Jessica Kerr @kenny_baas @joaoasrosa