Collaborative modelling domain boundaries
Slides
About
As a business, we want to make sure our software can handle changes when the business changes. We want to define boundaries that support the flow of the business value. Within Domain-Driven Design we have the perspective of strategic design. A perspective where we can split a large-system into multiple sub-domains, each having its purpose and responsibilities. Within these sub-domains, teams can work in autonomous, clean bounded contexts. One of the most effective ways to define these boundaries is by collaborative modelling with all the stakeholders involved in these domains. But that poses real challenges; What exactly is the definition of a (sub)domain? What is problem space? How can we form a common language of these boundaries? How does a customer journey fit in? And how do you decide and come to a single model in a large group, where everyone shares that same model on a high level?
Join us in this talk where we will show and tell war stories about our experience of having done collaborative modelling in several companies. We will tell our successes, but more importantly our failures and what we learned from them. What are the key heuristics we think that makes a collaborative modelling session with 30+ people, without any DDD knowledge, succeed? What are the skills we need to learn to facilitate it, and how can we make a company not dependent on us as consultants to continue their journey? You will leave with the knowledge of how to start your own collaborative modelling of your domain boundaries. We tell you our definition of (sub)domains, problems and solution space, and how we explained it to the companies we consulted. Providing you with new perspectives on how to embed this as a ritual in your company.
Visual and Collaborative modelling
Slides
About
The way agile software teams gain knowledge about what to build is either by the product owner or business analyst serving as a proxy to domain knowledge. Domain knowledge usually ends up as second-hand news in either functional design documents or as user stories in some scrum tools like Jira. Second-hand knowledge is a significant risk when building software. Each time information is transferred just like doing the telephone game, the story is changed, and people make assumptions. Because as Alberto Brandolini said: ‘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’.
Even when these stories are shared first hand, they usually are discussed sitting around a table looking at a screen showing the user stories. Addressing complex problems without visualisation is impossible for most humans to solve. Doing so resolve in making a lot of assumptions again, which will stop us from building the right thing.
Join us in this session where I will explain how visual collaborative modelling can help you write and deliver better software. Through proper preparation and facilitation, we can co-create solutions. Co-creating solutions by visual collaborative modelling make sure we have buy-in from the entire team. You will end up knowing how to start your visual collaborative modelling journey with tools like EventStorming and Example Mapping.
Tackling socio-technical complexity in the heart of your team
Slides
About
As a software engineering team, we want to solve complex business problems in the most efficient way possible. We invest a lot in technology to improve our team flow and try to make our technology process sustainable. We’ve got quite compulsive about automation and autonomy in achieving this. However, we are still tribal creatures that require tribal safety. Which means that if we want to make our technology process sustainable, we must also invest in people. For that, we need to tackle socio-technical complexity in the heart of our team.
In this session, Evelyn and Kenny will introduce you to the concept of socio-technical systems. We will explain what socio-technical complexity we are facing when building software to improve our team flow. How you can get a sense of the type of complexity you’re dealing with by using the Cynefin framework. Cynefin can aid your decision-making process by helping you make less biased decisions on how to approach your software development flow with your team. Finally, we’ll show you how visual collaboration tools like EventStorming and many others can help you visualise complexity. You will leave this session knowing how to start tackling socio-technical complexity in your team. Making sure you create a sustainable technology process for your team flow!
From EventStorming to CoDDDing
Slides
About
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.
Older talks & hands-on
Webinar: Domain Driven Design & Data Mesh
Data mesh is a decentralized sociotechnical approach for data management. Focusing on the technology, we tend to neglect the socio aspect of moving to new decentralized approaches. If we want to invest in data mesh architecture work, we must also invest in the people to make our data mesh more sustainable. How do we make people feel responsible for the data they expose and use? How do we make data management meet business objectives instead of a bureaucratic burden.
Decentralized approaches, e.g. like microservices, have been around for a while now. And we notice similar patterns of companies moving to a microservices architecture happening again when moving towards data mesh. Join this webinar to learn from these experiences and prevent obstacles for the future.
Hands-on: Crunching ‘real-life stories’ with DDD EventStorming and combining it with BDD Example Mapping
The way agile software teams gain knowledge about what to build is either by the product owner or business analyst serving as a proxy to domain knowledge. Domain knowledge usually ends up as second-hand news in either functional design documents or as user stories in some scrum tools like Jira. Second-hand knowledge is a significant risk when building software. Each time information is transferred just like doing the telephone game, the story is changed, and people make assumptions. Because as Alberto Brandolini said: ‘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’.
To really understand what our users will need, we want to have a first-hand experience from ‘real-life stories’ before we can model and create our software. While both the DDD and BDD techniques emphasis on ‘real-life stories’ by doing visual collaborative modelling, they both focus on different goals. DDD focuses more on creating bounded contexts in which a single model is created, BDD focuses more on different scenarios and can create executable specifications as an outcome. By doing EventStorming and using techniques from BDD such as Example Mapping, we can create more insights. We can simultaneously create a model and executable specifications for our user needs. This way, we can write software and tests which matches the shared understanding of the user, creating a ubiquitous language. Value will be shipped at a faster pace.
In this hands-on session, we start with EventStorming for software design, slowly gaining domain knowledge of what we need to build. By switching to Example Mapping we get more insights into our domain. Eventually we can end up designing a model for our domain with out formalised scenarios to test them. You will experience how EventStorming and Example Mapping you can create a shared language between business and IT that will drive your software modelling, building and testing.
Hands-on: A quest at mapping Domain-Driven Design Heuristics
“We all use heuristics (even if we haven’t articulated them to others) to discover, understand, explore, create, modify, or extend complex software systems. Billy Vaughn Koen, in Discussion of the Method: Conducting the Engineer’s Approach to Problem Solving, defines a heuristic as, “anything that provides a plausible aid or direction in the solution of a problem but is in the final analysis unjustified, incapable of justification, and potentially fallible.”
-Rebecca Wirfs-Brock
You can look at heuristics as a rule of thumb, they don’t guarantee to be optimal, perfect, logical or rational. Instead, they are based on our past experiences, not scientifically proven to work, but worked for us in the past. The thing about designing software is that nothing is certain. Every time I hear someone say ‘it depends’ that is a trigger for me to find out their heuristic. With this in mind, and by talking with Rebecca I started a site called DDDHeuristics.com in where we can collaborate to document and discuss these heuristics. In this session, I want to extend my search to ‘gotta catch em all’ and see how together we can map our Domain-Driven Design Heuristics. After a short introduction about heuristics, we will start exploring, distilling and mapping our own heuristics stories. With these stories mapped out we can find and share individual heuristics. We document them in a certain flexible way, where we have a question, the heuristic and give some examples and context. At the end of the workshop, you should get a clear overview of what heuristics are, how it can help you design, and how you can map them out in order to drive and implement your design and software.
Hands-on: EventStorming: continuous learning between multiple disciplines
To understand what our users need to make we sure build and test the right thing, we need first-hand experience of real-life stories before we can model, test and create our software. EventStorming is a technique that uses visualisation to minimise assumptions by doing continuous discovery between multiple disciplines. In this session, you’ll experience the basics of EventStorming hands-on.
Talk: I got Trapped! Systems thinking traps of IT Teams and how to battle them
Donella Meadows book, Thinking in Systems, is a concise and crucial book offering insight on how to think about systems, how to control systems and how systems change and control themselves. A system is a group of interacting, interrelated or interdependent parts unified to have a purpose. Examples can be a heating system, a tree, a human, a social system, an IT system, and IT Teams working as a part in a company which is also again a system.
For me, the most interesting part of the book is about system traps. They are traps in where systems can go wrong without notice. Since reading the book I started observing these traps in my day to day work. Traps like seeking the wrong goal with a code coverage threshold, shifting the burden to an intervener by letting a separate QA team be responsible for quality. Join me in this talk where I will go into more of these system traps I observed in IT teams, and what I did to get out of these traps.
See all my slides at speakerdeck