Gien Verschatse
BlunderingGoddess<'T>
Actions
Gien Verschatse is an experienced consultant and software engineer that specialises in domain modelling and software architecture. She has experience in many domains such as the biotech industry, where she specialised in DNA building. She's fluent in both object-oriented and functional programming, mostly in .NET. As a Domain-Driven Design practitioner, she always looks to bridge the gaps between experts, users, and engineers.
Gien is studying Computer Science at the OU in the Netherlands. As a side interest, she's researching the science of decision-making strategies, to help teams improve how they make technical and organisational decisions. She shares her knowledge by speaking at international conferences.
And when she is not doing all that, you'll find her on the sofa, reading a book and sipping coffee.
Badges
Topics
When To Move From Collaborative Modelling to Coding?
Managing polarities in software design and engineering.
When can we actually start coding? How do you know when you have done enough collaborative modelling? How can we make our architecture and design really iterative?
Domain-driven design puts a huge focus on collaborative modelling to build a shared understanding of your domain and we use a lot of tools like EventStorming, Example Mapping, Whiteboard sessions and Responsibility mapping to get to that shared understanding. But when it comes to questions like “when do we start coding?’, and “How much collaborative modelling is needed?”, it is often difficult to find a good answer or the answer you receive is “it depends”.
The reason that it is so difficult to answer those questions is because we are looking at these questions in the wrong way. We look at them like a problem we need to solve, instead of what it actually is: a polarisation that needs to be managed. If we don't learn how to recognize and manage polarities, we will make compromises or stay on one side of the polarity and experience the downside of both. To identify and manage polarities, we need to discuss and start using polarity mapping.
In this session, we will interactively introduce you to polarity thinking. We will explore how to identify polarities and how to manage them with Barry Johnson Polarity Mapping. We will explore too much vs too little upfront design, by filling in the polarity map together, we show you the power of visualisation to manage the polarity. We will go from either-or thinking to both-and thinking, and this way include the entire team in managing that polarity. You will leave the session knowing when to go from collaborative modelling to coding and fill in the polarity map with your team the next day!
Modelling Constraints
(This is a hands-on lab with limited capacity)
In this hands-on lab, we will focus on modelling business rules and constraints.
Business rules and constraints are everywhere. They can be the backbone of a business process or accidental to guide the business flow in the right direction. By writing them down explicitly as first class concepts, we get a number of benefits:
- We can discuss them with the domain experts;
- We can connect rules with the events that affect them. This helps to uncover hidden dependencies;
- We can use them as a guide to design boundaries. They can even help us to spot where our boundaries aren’t as isolated as we’d want.
Let’s upgrade our EventStorming by modelling business rules and constraints more granularly than ever.
Devils, Wizards and Decision Making Heuristics: Magic 8 Balls to the Rescue
Coffee or tea? One sugar or two? Should we use Event Sourcing or does CRUD seem good to you?
Our brains are designed for making quick decisions, but quick does not always mean good… We make thousands of decisions each day but never stop to wonder: how did we come to this conclusion? Were there more choices than we realised? Did we focus on the right thing? Did we pick the right option? Are there other methods we can use to reach a better outcome?
If we improved our decision making by just 1%, overall we would achieve a massive improvement in every area of our lives, from happiness with our family to success at work. Everybody should learn decision making heuristics, yet nobody does. Let's fix that.
We're going to take a close look at a variety of key decision-making heuristics including "problem restatement", "devil's advocate", and "the wizard". Through provocative exercises, we're going to uncover the heuristics we currently use and we're going to teach ourselves when to apply certain decision making heuristics to improve our chances of getting the results we want.
Bounded Contexts: Manage the Understandability of Your Systems
From Parnas' paper in the 1970's to microservices in the 2010's, we've always used modularisation as a way to manage complexity in software. And yet, we still end up with big balls of mud. Technical separation alone isn’t enough. We’ve also tried separating into business domains, but that’s not enough either: software wants to be deeply interconnected, spanning different domains, and doesn’t respect those boundaries.
Bounded Contexts provide an alternative to splitting on domains or on technical modules. We can separate by looking at the semantics. The domain models that underlie our systems, the language that is being used, and the meanings of the terms. We can draw “understandability boundaries”: separations that look at how concepts in our system are understood together (or can be understood autonomously). If we organise the teams along the same lines, then team members will need to understand fewer concepts to be productive. Teams will need less coordination with other teams. Having better semantic boundaries lowers the cognitive load.
Doing this kind of work is not free. But in the 20 years since the concept was introduced in Domain-Driven Design, we’ve developed patterns and heuristics to guide us.
Aggregates: An In-depth Examination
Aggregates serve as a means to encapsulate and manage related domain objects within a boundary, ensuring consistency and integrity. Understanding the scenarios in which aggregates are required is crucial for effective system design. It is also one of the most misunderstood concepts in Domain-Driven Design.
When considering aggregates within the context of bounded contexts (BC), it raises questions about their relevance:
- Why and when do you need an aggregate?
- Are aggregates exclusively an internal concern, relevant only within a specific BC, or do they extend their usefulness beyond these boundaries?
- Is there a difference between invariants as perceived from the outside of a BC/service and from the inside?
This talk delves into the nuanced world of aggregates, investigating their necessity, utility, and the significance of their boundaries. We explore the fundamental questions of why and when aggregates are essential in system design and how their presence contributes to maintaining consistency and integrity. Attendees can expect to gain insights into the practical implications of aggregates, fostering a deeper appreciation for their role in effective system design.
Collaborative Software Design: How to facilitate design decisions
Designing a software system is difficult. Understanding the context in which a software system lives is more difficult. In order to understand that context, developers need to communicate with the business. But there is a lot that can go wrong while communicating with the business. For example people can misunderstand what is being said, they are scared to speak up, tensions could grow, and conflict can arise. These social dynamics cause groups to stop sharing their knowledge, which can end up in resistance behaviour from sarcastic jokes, to stopped communication or even not showing up or leaving the session. No wonder a lot of organisations resort to a more autocratic form of decision-making, where one person, the architect, analyses and makes the decision. If we want to make sustainable design decisions for our architecture that is embraced by everyone, it is better to use visual techniques to make assumptions more explicit which will improve collaboration between developer teams and the domain experts.
In this talk we will introduce you to collaborative modelling and its social dynamic challenges. Collaborative modelling is a visualisation technique to analyse complex and conflict-laden decision-making processes with all relevant stakeholders and decision-makers to create a shared understanding. And some, maybe even most of these sessions need to be facilitated so that everyone can feel a part of the decision and can potentially give the input they have. I will explain why it requires us to have a different skills set like observing, listening, trying to stay neutral and show compassion. Because that improved collaboration will let software teams understand better the context and underlying problems the business has. That understanding enables the software teams to design and build sustainable quality software products.
DDD Europe, EventCentric, Data Mesh Live - 2025 Sessionize Event Upcoming
KanDDDinsky 2024 Sessionize Event
Domain-Driven Design Europe 2024 Sessionize Event
KanDDDinsky 2023 Sessionize Event
Copenhagen Developers Festival 2023 Sessionize Event
Domain-Driven Design Europe 2023 Sessionize Event
Newcrafts Paris 2023 Sessionize Event
TEQnation 2023 Sessionize Event
KanDDDinsky 2022 Sessionize Event
Domain-Driven Design Europe 2022 Sessionize Event
Domain-Driven Design Europe 2021 Sessionize Event
NDC London 2021 Sessionize Event
Distributed Domain-Driven Design Day (DDDDD) Sessionize Event
Domain-Driven Design Europe 2020 Sessionize Event
Domain-Driven Design Europe 2019 Sessionize Event
Please note that Sessionize is not responsible for the accuracy or validity of the data provided by speakers. If you suspect this profile to be fake or spam, please let us know.
Jump to top