Effective software design relies on integrating diverse perspectives throughout its development process. Research shows that teams with a neuro-diverse background excel in decision-making due to their ability to consider a wider range of ideas, foresee a greater variety of potential challenges, and develop more creative solutions. This becomes particularly clear in collaborative modelling for Domain-Driven Design. The inclusion of varied viewpoints enhances the ability of software models to address business problems effectively, increasing the likelihood of achieving significant product breakthroughs.

However, one social system significantly blocks the flow of development of these diverse perspectives: patriarchy. Patriarchy is a social construct where men predominantly hold power and exercise dominance in areas such as political leadership, moral authority, social privilege, and property ownership. Feminists have been actively working to challenge and change this patriarchal system for the better. Despite these efforts, the system still favours men, maintaining their dominant status, and will not evolve without their active involvement. Additionally, patriarchy limits men as well, endorsing only traits traditionally seen as 'masculine' and disregarding those seen as 'feminine.' This raises the question: how do we start the process of eMANcipation, involve men in the movement towards feminism, and as a result, improve our software design practices?

Join me in this talk as I explore patriarchy and its significant effects on software design. Drawing from personal experiences, I will discuss how patriarchy affects men and argue that for genuine equality, men need to undergo changes too. I will demonstrate how incorporating Process Work and Deep Democracy into software design can bring about the necessary transformation. By adopting the idea of role fluidity, we can start breaking down the patriarchal system in software design, ensuring that every perspective is appreciated and nurtured. You will leave with a deeper understanding of how patriarchy influences software design and practical steps you can immediately apply to foster a shift towards a more inclusive environment.

Most products start with an initial software model, a model that is usually naive and superficial, based on shallow knowledge. Which makes sense, because you just started discovering and exploring that new product. So we typically start by identifying nouns and verbs and using these as the initial objects and methods to build in our code. While the initial model helps you start getting fast feedback for your product, once you get more feedback most of the time it isn’t a helpful model anymore. They usually don’t provide a rational expression of the primary concerns of the domain experts anymore as time progresses to build that product. Not having that expression can hold you back from making essential breakthroughs for your product, breakthroughs that can be the differentiation factor in the market. And even worse, implementing the model in code might not even support making these new breakthroughs.

Join us in this hands-on modelling and coding session focused on the significance of continuously refactoring your product's core domain model. We will introduce you to the context by guiding you through several collaborative modelling techniques such as Eventstorming, Domain Storytelling, Context Mapping, CRC-cards and more. Dive into coding challenges using C# and Java, where you'll witness firsthand the transformative power of supple design and a deeper model. By the end, you'll understand how continuously refactoring the model can be pivotal in driving product development breakthroughs. Whether you prefer pairing or ensemble programming, you'll depart with enriched practical insights and a deeper understanding of chapter 13 from the blue book by Eric Evans.

Creating multiple models for the same problem is one of the more important lessons that Domain Driven Design teaches us. It is a lot cheaper to quickly iterate over them and throw away less useful prototypes before we even start coding. However, creating multiple models can be hard. When we begin gaining insight from our domain, we suffer a lot from cognitive biases that get in our way to gain new insights. We need these insights before we even start thinking about modelling. Tools like event storming and example mapping can help us to deliberate discover, and battle these biases. They help you quickly gain insight into the problem space. But the fallacy here is that we can get locked into the tool, and get stuck again.

What you will learn
In this workshop, you will learn the essentials of event storming and how it can help you gain the necessary insights you need to deliver quality software. With our newly acquired domain knowledge, we can then start exploring the solution space. During the exploration, we begin to design and model multiple models for the same problem with Domain Driven Design patterns. This way of visualising gives us the power to quickly iterate over the different models and figure out which model will be the best to use for now. Eventually, we start our coding journey TDD style, iterating over the model to refactor towards deeper insights while discovering how hexagonal architecture may help us to protect our domain code from the technical concerns, in the long run.

Target Audience
This workshop is for you if you are a software architect or software developer.

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 noticing. 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.