Gien Verschatse is an experienced consultant and software engineer that specialises in domain modelling and software architecture. 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.
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 and teaching at international conferences.
And when she is not doing all that, you'll find her on the sofa, reading a book and sipping coffee.
NewCrafts Paris 2023
Product and Tech: 4 weddings and a funeral
The word ‘product’ is everywhere these days. There are so many different definitions out there, that is getting confusing. There is this belief in the software community that, in order to build good software systems, everything needs to be a product. That this is the best way to deliver value to your customers and that projects are no longer useful in the context of software development. But is this really true?
In this talk, I will explain my understanding of what a product is and what it isn’t in the context of software development. I will introduce a new concept called ‘streamlet’ and explain how it can help you with thinking in products and teams. I will clarify how Domain-Driven Design helps you with product vs project decisions.
NewCrafts Paris 2023
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. Perhaps technical separation isn’t cutting it. 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. We can separate semantically, looking at the domain models that underlie our systems, the language being used, and the meanings of 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, they need to understand fewer concepts to be productive, they lower cognitive load, and need less coordination with other teams.
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.