Virtual Domain-driven design

Automation is a frequently discussed topic in the development and test communities - and has been for many years. Similarly, patterns have been part of community discourse ever since the Design Patterns book was published in 1994. It appears to us that both suffer from periodic bursts of hype and long stretches of neglect.While working on the Automation Patterns portion of our new book Effective Behavior-Driven Development, we have had the chance to explore the nuances of context specific automation and pattern forms. Our knowledge of BDD-specific automation styles comes from many years of practical application in industry. However, our experience with patterns has, up until this point, been mainly one of consumption. That changed when we took a subset of our BDD automation patterns to this year’s EuroPLoP pattern workshops — and got a refreshed view of pattern authoring.We’re happy to share the insights gained and challenges remaining in a conversation with VirtualDDD.About the speakersSeb has been a consultant, coach, designer, author and developer for over 40 years. He has been involved in the full development lifecycle with experience that ranges from architecture to support, from C to Visual Basic.During his career, he has worked for companies large (e.g. IBM, Amazon) and small, and has extensive experience of failed projects. He's now an independent software consultant and author, promoting effective ways of working to the software development and testing community.Regular speaker at conferences and occasional contributor to software journals. Co-author of "Effective Behaviour Driven Development" (Manning), lead author of “The Cucumber for Java Book” (Pragmatic Programmers), and contributing author to “97 Things Every Programmer Should Know” (O’Reilly).He blogs at claysnow.co.uk and socialises as sebrose@mastodon.scotGáspár Nagy, the creator of SpecFlow & Reqnroll, bringing over 20 years of experience as a coach, trainer and test automation expert nowadays through his company, called Spec Solutions. He is the co-author of the books "Discovery: Explore behaviour using examples",  "Formulation: Document examples with Given/When/Then" and "Effective Behavior-Driven Development" and also leads SpecSync, aiding teams in test traceability with Azure DevOps and Jira. He is active in the open-source community through leading the Reqnroll project. Gáspár shares his insights at conferences, emphasizing his commitment to helping teams implement Behavior-Driven Development (BDD).

When developing your software products, be it coding, testing, user experience, product management, or all the other elements required to solve a customer need, do you understand what the rest of the people do to make that happen? What about the other people in your organisation, maybe working on different products or even other legs of the customer journey like sales, customer service, billing, and operations? Do you see how you fit into the big picture, and what your contribution is to the company vision and strategy? I suspect most of us neither have the time nor the opportunity to get a wider view, focusing on our little part of the bigger system instead and making the best of that.We know that a system is supposed to be more than the sum of its parts, but how can we make sure that the sum is positive? That is hard when we cannot see the forest for the trees.Let us employ systems thinking to give us a holistic perspective, by adding synthesis to our analysis skills so that we can explore and understand emergence. We all know reductionism well, working on parts in isolation but holism is required to provide important insights and knowledge to handle the complexity in domains we normally work in – especially where people are involved. Only then can we build sustainable and adaptive software systems.This is an introduction to systems thinking and its importance when dealing with complexity.About TrondSenior IT Consultant and sociotechnical practitioner.Trond is an IT architect and open sociotechnical systems practitioner with extensive experience working with large, complex, and business-critical systems in industries such as telecom, media, TV, and the public sector. His main interests are service-orientation, domain-driven design, event-driven architectures, and open sociotechnical systems. His mantra: Great solutions emerge from collaborative sense-making and design.

Software teams often reach for Kubernetes or similar prepackaged answers as default solutions to complex problems. But Kubernetes isn’t a strategy—it’s a tool. Using it prematurely can bury your team in unnecessary complexity and unwanted consequences. These ‘default’ answers reflect a deeper issue: we don’t understand the problem we're solving.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 Kubernetes (or other technologies) and instead ask: what problem am I really trying to solve?About GienGien 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 shespecialised 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.

When it comes to giving software teams the autonomy to make their own decisions, trust can be a delicate thing. This is particularly true when those decisions can have a wider impact on other teams and the overall system. If organizations are shifting towards decentralized decision-making, how do they replace the safety net of authority with trust through practices that put accountability closer to where the work happens?In this session, we'll explore the paradox between centralized and decentralized decision-making. We'll discuss how a centralized approach aims to prevent mistakes but can also block teams from developing business-centric solutions, while a decentralized approach can lead to more sustainable decisions and empowered teams.This will be an interactive, 1-2-all session. Andrea and Kenny will each present for ten minutes on their practices and experiences, followed by a ten-minute dialogue. The session will then open up to everyone for a broader conversation. We'll use a Miro board for sense-making exercises to help us model and explore these ideas together.

In this talk, we’ll explore quality as an emergent property of our teams, tools, and processes—not just something we test at the end. We’ll look at challenges like speed to market and enshittification(1), and how they impact our approach to quality.We’ll introduce practical ways to think about quality through attributes like testability, observability, and recoverability. Most importantly, we’ll explore why a quality strategy—not just a testing strategy—is key to building better products.(1) “Enshittification is a pattern in which two-sided online products and services decline in quality over time” by Cory Doctorow sourceAbout Anne-Marie CharrettI’m an electronic engineer by trade, but software testing found me while I was working on Layer 4 protocols—and I’ve been hooked ever since. In the past, I taught software testing as an adjunct professor at UTS. These days, I work in engineering leadership, consult with teams on quality I bring a systems thinking lens to building quality in products, shaped by years working across startups, enterprises, and tech companies. I also wrote The Quality Coach’s Handbook, which you can find on Amazon or Leanpub.

"I would have killed that if it was just me, 100%,” said Spotify founder and CEO Daniel Ek about Discover Weekly, a feature that would become one of Spotify’s most loved product features, almost a brand in itself.Designers and senior engineers were equally skeptical, but the team was still able to ship the feature.In this talk, you’ll learn how Spotify’s organisational culture of Agile management and autonomous teams enables innovation, using the Discover Weekly feature as an example.The speakerJoakim Sundén is a founding partner of Better Product Work,where he helps visionary leaders challenge the conventional way ofbuilding products. From 2011 to 2017, he worked as a Senior Agile Coachat Spotify, where he was part of a team collaborating with the CTO todevelop the company’s approach to customer-focused product developmentat scale. This model would later become world-famous as ‘the SpotifyModel’ of Tribes, Squads, Chapters, and Guilds. He now assists leadersin transforming and improving their organizations into models whereemployees are empowered to create innovative solutions that not onlycustomers love but also drive business success.

Did you know that crows are better than toddlers at generating novel solutions? It's true! In the earliest days of childhood, around the globe scientists have documented that human cognition struggles to generate novel solutions. But we are adept at imitation, transmitting and teaching the solutions that we see others put into practice. What does this have to do with software, and innovation, and the cultures we want to create for the communities we love? I'm a psychologist fascinated by cycles of innovation in developer communities, and I think a simple reframe lights the way forward for our industry: in this talk, rather than focusing on what drives individual developer productivity, together we’re going to focus on the science of what drives developers’ collaborative problem-solving. We'll dive into the cognitive architecture of problem-solving, as well as what I've learned from leading empirical research with thousands of developers.Dr Cat HicksCat Hicks is a psychologist for software teams and defender of the mismeasured. She is the author of the Developer Thriving framework, the AI Skill Threat framework, and the VP of Research at Pluralsight. Cat is the founder of the Developer Success Lab, an open science research lab that creates empirical evidence about how organisations and individuals can achieve sustainable, resilient innovation in technology and create more well-being for technologists. Cat is also the founder of Catharsis Consulting, a scientific consultancy that connects organisations to human-centred evidence strategies. Cat holds a Ph.D. in Quantitative Experimental Psychology from UC San Diego, serves on the Advisory Council of the University of San Diego Center for Digital Civil Society, and is the author of a forthcoming book on the psychology of software teams.

Have you ever wondered about what makes a good abstraction vs a bad one? Do you want to examine potential reasons why efforts to develop abstractions at a company or in a project take hold, and some don't? Or what it takes to develop an abstraction that reaches beyond the technical corner of your company or project and becomes something that helps actually shape how you think about the entire problem? Understanding the process of developing abstractions, especially as a leader, is really about understanding the process of grief. Even if you get to build the abstraction, it won't be the one you pictured, or envisioned. You're going to need to take the seeds you've born, carefully curated, and lovingly built up over time... And watch them die. To build an abstraction is to hold the heart of your humanity in your hands. Plant your soul into the ground, and be reborn. In this session, I'm going to introduce my thoughts on abstraction, how it works, why it sometimes works and why it sometimes doesn't, and how one can actually take an abstraction and flesh it out to the point where it takes on a life of its own. With that, you should be able to have a better grasp on how ideas can take root in a way that bridges people and domains together. Hazel Weakly Hazel spends her days working on building out teams of humans as well as the infrastructure, systems, automation, and tooling to make life better for others. She’s worked at a variety of companies, across a wide range of tech, and knows that the hardest problems to solve are the social ones. Hazel currently serves as a Director on the board of the Haskell Foundation, as a Fellow of the Nivenly Foundation, and is fondly known as the Infrastructure Witch of Hachyderm (a popular Mastodon instance). She also created the first official Haskell “setup” Github Action and helped turn it into an active community-maintained project. She enjoys traveling to speak at conferences, appearing on podcasts, mentoring others, and sharing what she’s learned with the world. One of her favorite things is watching someone light up when they understand something for the first time, and a life goal of hers is to help as many people as possible experience that joy. She also loves shooting pool and going swing dancing, both as a leader and a follower.

Systems thinking is the macro behaviour that we must understand in analyzing our world. A system always produces what it is designed to do, even if that isn't at all what we meant it to do! Systems are self-maintaining, and contain balancing and/or reinforcing feedback loops. We'll look at how these work, and what happens when they fail. You'll see how to apply systems thinking to the systems that are all around us. This is an introductory talk to the world of Systems Thinking, condensed into 45 mins plus time for questions at the end.

From example mapping, to BDD, to DDD practices like event storming and domain storytelling, we're fortunate to have a wide range of tools for collaboratively building domain knowledge and creating models of those domains in software. One gap that many organisations experience is the management of that domain knowledge over time. Domains evolve. Team members learn new aspects of the domain, or invent more useful models. Team members leave - taking knowledge with them, and new members join but never get the chance to participate in foundational collaborative modelling sessions. Living documentation is a set of practices to help ensure institutional knowledge is reliable, collaborative and low-effort. In this session, Chris will do some live domain modelling with volunteers from the audience to demonstrate a new approach to capturing domain knowledge as living documentation, and how to use open source tools like Contextive (https://contextive.tech) to help ensure the knowledge is absorbed, maintained, and relevant over time.

The strongest tech skills don’t necessarily guarantee success. To get the best from those around you—and maximize your own influence—you need to boost your tech skills with soft skills. Luckily, small changes in the way you work can produce big results. In this free webinar, Jacqui Read, author of Communication Patterns: A Guide for Developers and Architects, takes you on a whistle-stop tour of patterns and techniques to improve your visual, verbal, nonverbal, written, knowledge, and remote communication skills. You’ll learn communication soft skills tuned specifically to a technical audience, which you can easily integrate into your existing workflows for quick and transformative results. You’ll learn how to:     Use soft skills to boost your technical skills     Explore visual, nonverbal, written, knowledge, and remote communication skills     Integrate communication soft skills into your everyday workflow for transformative results  

When building event-driven architectures, one of the challenges we face is coordinating work across many services. How do we implement complex data flows or complex business transactions that consist of multiple asynchronously executed steps? Luckily, there are patterns that can help us manage this complexity: orchestration and choreography. Join us in this fireside chat with Udi Dahan and Laila Bougria as we discuss how each pattern works, the pros and cons of each, and the trade-offs involved when choosing one over the other in specific contexts. See you there!

As systemic complexity increases around us, many technologists are redefining “leadership.” What is technical leadership when good decision-making depends on collective, cross-functional thinking? How is collaborative modeling a form of leadership? What type of leadership does a systems architect provide? Eb Ikonne, author of “Becoming a Leader in Product Development: An Evidence-Based Guide to the Essentials”, opened our open space event with a keynote. Eb will create the context for our discussions, describing adaptive leadership as something we can practice and a skill we can cultivate. This is the extract of that keynote.

As the relational complexity of software increases, we need, more than ever, smart architecture. Domain-aligned, team-decoupling, cohesiveness-driving, constantly evolving architecture has a massive positive impact. To design systems, we need to evolve the role of “architect” away from the dualistic most-experienced implementor vs ivory tower strategist.  Architecture is a technology-agnostic skillset. You practice it regardless of which tools or programming language you work with. Architecture practice is a solitary, intra-group, and inter-group activity. We practice it within the human system, when we collaboratively design patterns and relationships, empower decision making and construct cross-functional feedback loops. In this talk, we explore: * “What is an architectural decision?” (The answers might surprise you).  * How do we work effectively individually, intra-team, and inter-team to make them? * What is the “advice process” and what has it taught us?

Does your team suffer from: Inconsistent views of your systems? Producing incohesive solutions? Ineffective architecture practices and tools? Introducing Bytesize Architecture Sessions! Bytesize Sessions are a workshop format that enables collaborative and iterative knowledge sharing. This talk will enable you to run Bytesize Sessions resulting in the following benefits: Improved systems thinking. Enriching collaboration within the team. Understanding architecture practices and tools in a safe environment. A feedback loop controlled by the team produces better documentation across sessions. Revealing the Bermuda Triangles! About Andrea Magnorsky Andrea is a professional software developer with over 20 years of experience. These days she is a consultant / contractor focusing on strongly typed functional languages and software architecture . Andrea founded Kats Conf, Global GameCraft and many other communities. She also co-founded BatCat Games, a PC and Console game development company in Ireland.  

oday most software products are highly networked and distributed solutions used by 1000s if not -10000s of people spread across the globe. To produce an experience that is intuitive and delivers a quality service worldwide, multi-culturally, and 24/7 across all time zones, you need a multi-disciplinary and diverse set of individuals i.e. a tailored team. Join us in this panel with: Dawn Ahukanna Jessica Kerr Ruth Malan Rebecca Wirfs-Brock Mathias Verraes Trond Hjorteland

There is a quote made famous by Ruth Malan from Grady Booch: "Architecture represents the significant design decisions that shape a system." And shaping a system takes time, and seeing the impact of these significant design decisions can take years after the changes have been done. And most of us are usually not there to reak the benefit, or worse, feel its pain. So in collaboration with D-EDGE we will have a panel of people that did experience and will discuss how architecture decisions shaped the system years after the change.    

Our models should be driven by the domain, but not constrained by what domain experts tell us. After all, the domain language is messy, organic, ambiguous, social, incomplete, and if it has any intentional design to it at all, it's not designed to be turned into software. Modelling is more than capturing requirements, it's the opportunity to create novel concepts. This talk will use real-world stories to invite you to discuss.

In the last week of this year, we are closing another full year of virtual Domain-driven design meetups with the last meetup. So grab your drinks (tea, lemonade or anything you want!) and come join with your DDD questions to this lean coffee! We all post topics we want to discuss and together we will get into dialogues, so bring us your knowledge and DDD questions and see you then! Miro https://miro.com/app/board/uXjVOY0dIIk=/

The term “sociotechnical” seems to have gotten a bit or renaissance lately, which is a great thing given all the positive impact it has had on many organisations and their workers around the world over the years. It also seems to have gotten some traction outside the academic circles this time after being developed and pushed from there mostly using action research since its humble beginning in the post-war British coal mines. It is an entry into systems thinking for many, with its idea about joint optimisation of both the technical and social aspects of an organisation. A common example is setting up the team topology to match the service architecture in an attempt to cater for negative effects of Conway’s law. This is all well and good, but if we think about it, viewing the modern organisation as a sociotechnical system is a bit of a tautology; all organisations have social and technical elements that people deal with on a daily basis. As with systems thinking, the value of sociotechnical system design is more about perspective and understanding rather than any specific outcome. There is so much more to sociotechnical design than DevOps and team setup that we need in order to cope in our increasingly complex and hazardous “digital coal mines.”