Domain Driven Design: from the trenches

You’ve probably heard about Domain Driven Design, heck you may have even read THE book on it, but like most of us you’ve probably wondered how to apply it in practice. Where do you begin? How do you win people over to this sometimes drastically different way of thinking and doing? In this short talk you’ll hear from both a UX Designer and Engineer on how they navigated the early stages of a project, the challenges encountered along the way and some of the techniques that were employed to overcome them. Finally, we’ll retrospect on the overall process of DDD and contrast the outcomes with those of other traditional approaches. Make sure you don’t miss this talk!

Transcript

2. DOMAIN DRIVEN DESIGN: FROM THE TRENCHES next up WHAT IS DDD?
3. INTRODUCTIONS
4. RAMI RUHAYEL Software developer, DDD evangelist & all around great guy Twitter LinkedIn Medium VALERIA SPIROVSKI Experience design, Iteration manager & Product facilitator INTRODUCTIONS next up WHAT IS DDD?
5. WHAT IS DDD?
6. DOMAIN DRIVEN DESIGN IS... WHAT IS DDD? A way to robustly represent the domain in the software so that it supports the desired experience and business outcomes The resulting software tells the story of the user in code. next up CONTEXT & TEAM SETUP
7. CONTEXT & TEAM SETUP Our context, and factors that helped us approach DDD
8. PROJECT SCOPE & TEAM SETUP CONTEXT & TEAM SETUP Scope - Had a high level vision and outcomes - Inherited a suggested design from a previous project as part of scope - Remit to explore Team Setup - Set up and funded as a team, not a project - Cross functional roles - SME embedded as part of the team next up CASE STUDY
9. CASE STUDY Our Journey
10. Project kick-off CASE STUDY
12. TRUCKS & DIGGERS ORIENTATION
13. DEVELOPING A UBIQUITOUS LANGUAGE
14. DOMAIN IMMERSION next up DEFINING OUR SCOPE
15. Defining our scope CASE STUDY
16. INHERITED DESIGN
17. A MODEL IS BORN next up THE EVOLVING STORY MAP
18. The evolving story map CASE STUDY
19. OUR FIRST STORY MAP
20. MANY COOKS, NO HEAD CHEF CASE STUDY NO PRODUCT OWNER Program Architect Program Lead Existing Design Program Tech lead Integration requirements New product features Inherited product features Tech platform requirements No Product Owner
21. STORY MAP next up ADDING A PRODUCT OWNER TO THE MIX
22. Adding a Product Owner into the mix CASE STUDY
23. A P.O. IS IN THE HOUSE
24. EVERYTHING GETS CHALLENGED Product Owner new to software delivery Was initially more of an SME next up DDD SPIN ON MODELLING
25. DDD Spin on modelling CASE STUDY
26. DOMAIN MODELLING
27. STARTING OUR MODEL DEFINITION ENTITY MODELLING: ENTITY
28. STARTING OUR MODEL DEFINITION ENTITY Entities have a persistent identity MODELLING: ENTITY
29. MINE SITE AGGREGATE REGION ENTITY MODELLING: AGGREGATE
30. MODELLING: AGGREGATE MINE SITE AGGREGATE REGION ENTITY A Aggregate is a cluster of domain objects that can be treated as a single unit
31. MODELLING: AGGREGATE MINE SITE AGGREGATE REGION ENTITY EMPLOYEE AGGREGATE Transactions never cross Aggregate boundaries.
32. EMPLOYEE AGGREGATE MODELLING: TRANSACTION BOUNDARIES AGGREGATE ENTITY AGGREGATE ROOT ENTITY
33. EMPLOYEE AGGREGATE MODELLING: TRANSACTION BOUNDARIES AGGREGATE ENTITY AGGREGATE ROOT ENTITY The Aggregate Root is the gateway to an Aggregate.
34. EMPLOYEE AGGREGATE MODELLING: TRANSACTION BOUNDARIES AGGREGATE ENTITY AGGREGATE ROOT ENTITY The Aggregate Root is the gateway to an Aggregate.
35. EMPLOYEE AGGREGATE MODELLING: TRANSACTION BOUNDARIES AGGREGATE ENTITY AGGREGATE ROOT ENTITY The Aggregate Root is the gateway to an Aggregate.
36. MODELLING: TRANSACTION BOUNDARIES AGGREGATE ENTITY AGGREGATE ROOT ENTITY Communication between aggregates is via Domain events AGGREGATE EMPLOYEE UPDATED EVENT
37. MODELLING: BOUNDED CONTEXT BOUNDED CONTEXT
38. MODELLING: BOUNDED CONTEXT BOUNDED CONTEXT A Bounded Context contains a unified, consistent model
39. CASE STUDY WHY DO WE NEED BOUNDED CONTEXTS? As you try to model a larger domain, it gets progressively harder to build a single unified model. Different groups of people will use subtly different vocabularies in different parts of a large organization. DDD SPIN ON MODELLING
40. CASE STUDY BOUNDED CONTEXTS MAKE INTERRELATIONSHIPS EXPLICIT DDD SPIN ON MODELLING next up TRYING OUT EVENT STORMING
41. Trying out Event Storming CASE STUDY
42. CASE STUDY EVENT STORMING • Collaborative facilitation exercise with team, domain experts and stakeholders • Use the concept of Domain Events to start understanding how domain experts operate. • Use the resulting event streams to inform the model WHAT IS EVENT STORMING?
43. CASE STUDY EVENT STORMING • Telling the story in terms of Domain Events tells the reality of what happened • Avoids future state, proposed or imagined states A REAL STORY
44. Domain Event Aggregate Actor Command External System PROVIDE A LEGEND
45. CASE STUDY EVENT STORMING We always start at the end with the last event, because it keeps us focused on the goal at hand. We then add the first event, creating a timeline all the way from the beginning to the end. Finally we walk through the model forwards and backwards to ensure that everything is covered. BUILDING YOUR EVENT TIMELINE
46. next up BRINGING EVENT STORMING BACK TO DDD REORGANISING OUR EVENT STREAMS TOGETHER EVENT TIMELINE next up HOW WE BROUGHT EVENT STORMING BACK TO OUR MODEL
47. How we brought Event storming back to our model CASE STUDY EVENT STORMING
48. DISCOVERING AGGREGATES USING EVENTS LAYOUT AGGREGATE
49. LAYOUT AGGREGATE DISCOVERING AGGREGATES USING EVENTS CLUSTER OF EVENTS
50. DISCOVERING AGGREGATES USING EVENTS Identify Aggregates that receive commands and publish events LAYOUT AGGREGATE
51. LAYOUT AGGREGATE DISCOVERING AGGREGATES USING EVENTS TRAIN SCHEDULE AGGREGATE next up CLOSING THE LOOP
52. CASE STUDY EVENT STORMING BRINGING EVENT STORMING BACK TO DDD The resulting model is then challenged with code in order to validate the group learning and verify the model. CLOSING THE LOOP next up TIPS FOR RUNNING AN EVENT STORMING SESSION
53. Tips for running an Event Storming session CASE STUDY EVENT STORMING
54. OWNING THE FACILITATION CASE STUDY EVENT STORMING TIPS ON SETTING UP AND RUNNING THE SESSION - Event storming is a medium to high difficulty facilitation framework - Practice facilitating, or engage an experienced facilitator - Plan the session beforehand
55. HAVE A LARGE, PERSISTENT SPACE
56. IT’S OK TO DISAGREE
57. Post-it notes in at least 4 different colours Sharpies Brown canvas paper & scissors Blue-tack!! STATIONARY: CASE STUDY EVENT STORMING TIPS FOR RUNNING AN EVENT STORMING SESSION next up THE EVOLVING PRODUCT STRATEGY
58. Evolving product strategy CASE STUDY
59. WHAT DOES PRODUCT STRATEGY MEAN? CASE STUDY EVOLVING PRODUCT STRATEGY
60. PRODUCT STRATEGY IN ENTERPRISE CASE STUDY EVOLVING PRODUCT STRATEGY
61. SITE VISIT INFORMED VALUE ROADMAP
62. When people have two different definitions for a term - discuss - review and refine the model. MAINTAINING A UBIQUITOUS LANGUAGE
63. Product strategy & concept evolved and then changed the model & architecture next up RETROSPECTIVE PRODUCT STRATEGY EVOLUTION
64. RETROSPECTIVE
65. RETROSPECTIVE
66. RETROSPECTIVE
67. Have fun RETROSPECTIVE next up QUESTIONS?
68. QUESTIONS? Just questions, no answers. Zen. Shout out to O.G. Canary <3