Diese Präsentation wurde erfolgreich gemeldet.
Die SlideShare-Präsentation wird heruntergeladen. ×
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Nächste SlideShare
The sweet spot
The sweet spot
Wird geladen in …3
×

Hier ansehen

1 von 111 Anzeige

The precision blade

Herunterladen, um offline zu lesen

Using EventStorming to drill into domain modelling complexity: from the big picture into the design of aggregates, processes and read models. A different approach to enterprise software modelling.

Using EventStorming to drill into domain modelling complexity: from the big picture into the design of aggregates, processes and read models. A different approach to enterprise software modelling.

Anzeige
Anzeige

Weitere Verwandte Inhalte

Diashows für Sie (20)

Andere mochten auch (17)

Anzeige

Ähnlich wie The precision blade (20)

Weitere von Alberto Brandolini (15)

Anzeige

Aktuellste (20)

The precision blade

  1. 1. DDD EUROPE PRESENTS…
  2. 2. A @ZIOBRANDO PRODUCTION
  3. 3. IN THE LAST EPISODES…
  4. 4. NOBODY TALKS ABOUT THEIR DOMAIN
  5. 5. WHO CAN BE THAT STUPID?
  6. 6. ABOUT ME • Started coding in 1982 • Entered DDD in 2005 • Met Eric • Started Avanscoperta • Met Greg • Event-Based Modelling in 2012 • Blast during Vaughn’s tour • EventStorming in 2013 • Started EventStormers community • 348 members (on Google+)
  7. 7. SOFTWARE DEVELOPMENT IS A LEARNING PROCESS
  8. 8. WORKING CODE IS A SIDE EFFECT
  9. 9. I USE INSTEAD
  10. 10. INVITE THE RIGHT PEOPLE PEOPLE WITH QUESTIONS PEOPLE WITH ANSWERS A FACILITATOR
  11. 11. PROVIDE AN UNLIMITED MODELLING SURFACE “ AND BE PREPARED TO EXPAND IT
  12. 12. MODEL WITH DOMAIN EVENTS ALONG A TIMELINE “
  13. 13. REALLY SIMPLE
  14. 14. THEN IT GROWS…
  15. 15. (EXTERNAL SYSTEMS, IN PINK) AND GROWS…
  16. 16. (HOTSPOTS, IN PURPLE) AND GROWS…
  17. 17. THE GOAL(S) OF A BIG PICTURE EVENTSTORMING
  18. 18. 1. ARE WE SOLVING THE RIGHT PROBLEM?
  19. 19. ARE WE SOLVING THE RIGHT PROBLEM? CALL IT “CORE”, CALL IT “BOTTLENECK”… … PEOPLE WILL “TELL” YOU WHAT THE REAL PROBLEM IS AND PLEASE READ “THE GOAL” IF YOU HAVEN’T
  20. 20. DOES IT MATTER?
  21. 21. WHERE DETAILS ARE MAKING A DIFFERENCE… IN THE CORE DOMAIN… • Creative • Always looking for alternatives • Continuously refining solutions • Perfectionist
  22. 22. IN A FIXED-BUDGET NON-CRITICAL PART OF THE DOMAIN SOMEWHERE ELSE • Creative • Always looking for alternatives • Continuously refining solutions • Perfectionist TROUBLEMAKER
  23. 23. 2. CAN WE SUCCEED?
  24. 24. MAKING THE RISK OBSERVABLE EXTERNAL SYSTEMS & HOTSPOTS PEOPLE AND POLITICS
  25. 25. IS MY WALKING SKELETON
  26. 26. NOT EVERY BATTLE IS WORTH FIGHTING OUTCOMES • We’re on a problem worth solving: • let’s prototype a solution right now!! • Ouch! …the real problem is somewhere else. • Fine, let’s use the money more wisely. • Ouch! …they can’t even agree on the problem… • Shake hands, smile, and leave quietly.
  27. 27. LET’S ASSUME WE’RE LUCKY
  28. 28. OUR BACKLOG
  29. 29. • The involved Domain Experts • The Development Team (including UX) • a Facilitator • Unlimited Modelling Space • Unlimited Surface • Unlimited Supply of markers, stickies and so on • We’ll have only to take care of our limited Energy. OUR TEAM
  30. 30. TECHNICAL TRAININGS OUR SAMPLE DOMAIN • My Company —> We have a real domain expert here… • Public & Private Training and workshops, (plus coaching &mentoring).
  31. 31. HOW DID WE GET THERE?
  32. 32. MORE GUESSING THAN EXPLANATION
  33. 33. IT’S A LEARNING PROCESS!
  34. 34. SKIP THE BORING PARTS IF THERE’S TIME: THE REAL REASON WHY I AM NOT A PIANO PLAYER!
  35. 35. DONEC QUIS NUNC
  36. 36. LET’S TRY AGAIN!
  37. 37. A TICKET!
  38. 38. AND THE CORRESPONDING COMMANDS
  39. 39. ANY CANDIDATE NAMES…
  40. 40. WHAT IF SOMEBODY DOESN’T SHOW UP?
  41. 41. ANYTHING ELSE?
  42. 42. GETTING THERE…
  43. 43. • Can we transfer it? • Good question. In fact this never happen with individual purchases, they usually ask for a refund, or if they can reuse the ticket with a different edition of the same training class. • What can happen instead is companies, buying a group ticket, asking to switch people, or delaying actual participant names till he very last moment.
  44. 44. • Can we transfer it? • Good question. In fact this never happens with individual purchases, they usually ask for a refund, or if they can reuse the ticket with a different edition of the same training class. • What can happen instead is companies, buying a group ticket, asking to switch people, or delaying actual participant names till he very last moment.
  45. 45. I LOVE THIS MESS! CAPTURE IT! ALL OF IT. YES, EVEN IF IT MEANS A LOT MORE STICKY NOTES
  46. 46. ADD MORE SPACE!
  47. 47. — Anonymous WHAT IF TICKET IS AN ABSTRACT CLASS? WITH INDIVIDUAL AND GROUP TICKET AS SEPARATE SUBCLASSES ” “
  48. 48. … WE INVITED THE RIGHT PEOPLE!
  49. 49. • There’s no need for any automatic operation. It only happened once. Doing it manually (whatever that means) is fine.
  50. 50. • Talking with the right people, we might get the answers we like. • The complexity is in the domain, it’s just not necessarily worth implementing.
  51. 51. 1. MAKE IT VISIBLE 2. SAFELY IGNORE IT
  52. 52. — Anonymous Developer WHAT ABOUT PRIVATE CLASSES? AREN’T THEY THE SAME THING ” “
  53. 53. THINKING ABOUT DATA… Headline Description Duration Trainer City Date Venue Headline Description Duration Trainer PRIVATE PUBLIC
  54. 54. THINKING ABOUT BEHAVIOUR… Scheduled Base Price defined Sales Opened Confirmed Cancelled Sold out Delivered Replanned Planned Signed off Scheduled Delivered PRIVATE PUBLIC NOT ALIKE
  55. 55. TWO INDEPENDENT PROCESSES IN SALES BASICALLY THE SAME PROCESS, IN CONTENT DEFINITION
  56. 56. MAYBE THEY DO BELONG SOMEWHERE… WHAT ABOUT SEATS
  57. 57. EXPLORING THE RELATIONSHIP
  58. 58. THERE’S SOMETHING MISSING
  59. 59. POLICY IS A GOOD NAME FOR IT BUT YOU CAN FIND ALSO “PROCESS” OR “THE WHENEVER BOX”
  60. 60. DO WE REALLY NEED THAT? LET’S ASK THE DOMAIN EXPERT • Aren’t they the same thing? • Not at all. We need to add the trainer to the participants. Room capacity and coffee breaks plus lunch are based on the total number of people in the class. • Moreover: the trainer might bring a co-trainer, the company can have an internal person in the class, or there can be “guests” that are not passing through the ticketing system. • We’re currently creating “fake tickets” for everybody in order to have all participants in the same container, but one single mistake and everything fall apart.
  61. 61. (ET VOILÀ) INDEPENDENT MODELS! TRAINERS DON’T NEED TO BUY A TICKET EVERYONE IN THE TRAINING ROOM DESERVES SOME GOOD COFFEE, AND A GOOD LUNCH
  62. 62. — Ziobrando IN A RESTAURANT, IF YOU’RE THE TRAINER, YOU GET EXACTLY THE SAME FOOD ” “
  63. 63. ISN’T THAT TOO COMPLEX?
  64. 64. MORE PRECISELY
  65. 65. DO WE HAVE TO IMPLEMENT IT? BOUNDED CONTEXTS ARE HEAVY… ?
  66. 66. IT DEPENDS…
  67. 67. UNDERSTANDING THE PROBLEM MUST BE CHEAP
  68. 68. A PROPER IMPLEMENTATION IS VALUE VS COST
  69. 69. ARE WE IN THE CORE?
  70. 70. NO. THE REAL PROBLEM IS… DAMN, WE WERE JUST WANDERING…
  71. 71. (A) REAL PROBLEM • We were stuck in go/no-go decisions • Collaborators didn’t know whether to cancel or confirm the class • I needed to explain my decision making process.
  72. 72. “WHAT IS THE DATA NEEDED IN ORDER TO TAKE THIS DECISION?”
  73. 73. THIS IS SCARY HOW MANY AGGREGATES SHOULD I QUERY?
  74. 74. ENTER READ MODELS
  75. 75. SO MANY WAYS HOW CAN WE IMPLEMENT IT? • Projections • Composite UIs (including mashups) • Denormalisation • Good old queries (not forbidden, just uncool)
  76. 76. WE MOVED THE BOTTLENECK!!
  77. 77. NOW, THE REAL PROBLEM IS…
  78. 78. WE DON’T SELL ENOUGH • Some training class are good, but not appealing • Users don’t take the BUY TICKET decision.
  79. 79. “WHAT IS THE DATA NEEDED IN ORDER TO TAKE THIS DECISION?”
  80. 80. NOT THAT SIMPLE…
  81. 81. THIS IS A PIZZA. IT IS FOOD, THAT PROVIDES THE CALORIES AND THE ENERGY YOU NEED IN ORDER TO SURVIVE TILL THE NEXT MEAL. IT IS AVAILABLE IN SEVERAL SIZES AND TOPPINGS. CONTACT US IF YOU WANT TO KNOW MORE.
  82. 82. Order now! Feeling hungry?
  83. 83. IT’S NOT ONLY THE DATA…
  84. 84. USERS AREN’T ONLY RATIONAL DID ANYONE NOTICE THAT I MENTION THE UX PEOPLE?
  85. 85. AND IT’S NOT THE SAME DATA
  86. 86. HIS OWN MONEY, KNOWS THE STUFF. COMPANY MONEY. NEEDS PERMISSION. COMPANY MONEY. CALENDAR IS IMPORTANT. NEED SAFETY AND DISCOUNTS.
  87. 87. OUCH! WHY CAN’T ANYTHING JUST BE SIMPLE?
  88. 88. CHOOSE A TARGET, AND RUN AN EXPERIMENT.
  89. 89. IT’S ABOUT THE QUESTIONS, NOT THE NOTATION
  90. 90. WE’RE MODELLING A FLOW OF DECISIONS
  91. 91. WE’LL HAVE TONS OF IDEAS
  92. 92. NOT ALL OF THEM WORTH PURSUING
  93. 93. MOSTLY UX DRIVEN EXPLORATION MAKING SENSE OF DATA, FROM TRIVIAL TO BI, TO BIG DATA TRADITIONAL SOFTWARE ARCHITECT’S REALM THANKS TO GREG’S SQUIRREL ;-)
  94. 94. THE GOAL IS NOT TO WRITE COOL SOFTWARE
  95. 95. THE GOAL IS TO SOLVE THE RIGHT PROBLEM IMPACT MAPPING - NO ESTIMATES - USER STORY MAPPING
  96. 96. KEEP THE MODELS SIMPLE
  97. 97. CAN’T ACHIEVE SIMPLICITY WITHOUT DIVING INTO CHAOS
  98. 98. KEEP THE PROBLEMS SIMPLE
  99. 99. MODELLING THE FLOW WITHIN THE SPACE CONSTRAINTS THIS IS THE ACCIDENTAL SELF-INFLICTED COMPLEXITY NOBODY WILL PAY YOU FOR
  100. 100. THANK YOU!
  101. 101. WANT TO KNOW MORE? • Really fresh: www.eventstorming.com • LeanPub book in progress: • http://leanpub.com/ introducing_eventstorming • Blog: http://ziobrando.blogspot.com • Twitter: @ziobrando • Trainings & Workshop facilitation: • http://www.avanscoperta.it

×