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

From EventStorming to CoDDDing @ Bucharest Soft...

From EventStorming to CoDDDing @ Bucharest Software Architecture Summit 2021

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!

João Rosa

May 21, 2021
Tweet

More Decks by João Rosa

Other Decks in Technology

Transcript

  1. 2 CTO a.i Strategic Software Delivery Domain-Driven Design Sociotechnical system

    student Trainer, podcaster and author @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 @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 @joaoasrosa
  4. 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 @joaoasrosa
  5. 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 @joaoasrosa
  6. “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 @joaoasrosa
  7. 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 @joaoasrosa
  8. 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. @joaoasrosa
  9. 47 Try at least to find three models, even if

    you think you already found the “right model” @joaoasrosa
  10. 51 Source: https://nl.pinterest.com/pin/550846598149452758/ @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
  11. 53 1. Protects business invariants 2. Design them small 3.

    Reference other by ID only 4. Update other aggregates using eventual consistency @joaoasrosa
  12. 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
  13. 57 Software Development is a learning process, working code is

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

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