Gien Verschatse
BlunderingGoddess<'T> @ Aardling
Actions
Gien Verschatse is an experienced consultant and software engineer at Aardling. She 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
Area of Expertise
Topics
EventStorming; Continuous learning between multiple disciplines
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. Second-hand knowledge is a problem because ‘It is not the proxy’s knowledge that goes into production; it is the developer’s (mis)assumption of that knowledge that goes into production’.
Sharing knowledge is way more effective if we actively collaborate to gain new insights about the problem at hand. EventStorming is a technique that can facilitate visual collaborative modelling between the different disciplines. It is easily learned and empowers continuous knowledge sharing without the need to know a tool.
In this hands-on session, we will show you how easy it is to learn EventStorming and at the same time gain a lot of new insights about a new domain. You will experience how EventStorming can reduce requirements engineering from days to hours, increasing feedback, and ending up delivering the expected features.
When to go 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 that 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 polarization 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!
Domain boundaries are not enough: Connect Contexts and Services
Have you ever wondered why some software seems to be disconnected or even constantly fighting the business, while other systems grow naturally from it? The answer lies in domain modelling.
This talk explores the importance of continuously defining and modelling domain boundaries to design adaptable and resilient software systems. You'll leave with a clear understanding of what a subdomain is, how it differs from a bounded context and a service boundary, and why grasping this distinction is fundamental to good architecture.
Modelling domain boundaries with stakeholders is essential for building good software. We will explain how they are related to, yet distinct from, service boundaries and bounded contexts. We'll also present why designing and continuously adjusting these boundaries based on feedback is a good habit for creating software that aligns with the business and generates new opportunities.
We won't shy away from the complex challenges, either: the resistance to change, the disconnect between an ideal future and the weight of legacy systems, and the struggle of getting a group to agree on what a "customer" even means.
You'll get practical insights and design heuristics on how to collaboratively model these boundaries using techniques like Big Picture EventStorming, Domain Storytelling, Wardley Mapping, and Context Mapping.
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!
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.
Slow down to speed up your decision-making
In many software teams, decision-making is driven by habits, blindly following best practices, or the latest trends - rather than a clear understanding of the problem. Microservices are a perfect example. Teams often break systems into smaller services because it feels like the “right” approach and everyone else is doing it too. Before a single service is deployed, the architecture is already overcomplicated - not because of bad intentions, but because we never stopped to ask: what problem are we actually trying to solve?
Through real-world examples, we’ll discuss how to think critically about the way decisions are being made in your company. We’ll introduce concepts like participation theater—when people perform the rituals of decision-making without making real decisions—alongside problem restatement as a tool to uncover the real challenge at hand. We’ll also examine different types of decisions (reactive vs. proactive, reversible vs. irreversible) and why recognizing them early changes how you should approach them.
This talk is a call to slow down to speed up your decision-making. Whether you're an engineer, architect, or tech lead, this session will challenge you to pause before reaching for solutions and instead ask: *what problem am I really trying to solve?*
KanDDDinsky 2026 Sessionize Event
Digital Architecture Design Day 2026 Sessionize Event
Domain-Driven Design Europe and Data Mesh Live 2026 Sessionize Event
NewCrafts 2025 Sessionize Event
Global Software Architecture Summit 2025 Sessionize Event
DDD Europe, EventCentric, Data Mesh Live - 2025 Sessionize Event
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