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

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.

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.

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.

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.

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

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.

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.

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.

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=/

Some will say that you shouldn't even try to tackle a system bigger than what a typical agile team can absorb; others will say that agile just doesn’t scale beyond the simplest of systems. Experience suggests that reality lives somewhere between these two extremes, but where, exactly, is the clear and present question. In this talk, we’ll first consider the dimensions of scale - complexity, risk, and time - and then explore the ways that agility works (and sometimes doesn’t). Along, the way, we’ll study contemporary approaches to scaling agile, and conclude with an examination of work yet to be done.

Cat Swetel gave a brilliant Technologist's Introduction to Epistemic Injustice explaining "epistemic injustice"—what we know, how we know, and who gets to decide and influence our reality. There are two kinds of epistemic injustice: Testimonial injustice; When someone is ignored, or not believed, because of their sex, sexuality, gender presentation, race, or, broadly, because of their identity. Hermeneutical injustice; injustice related to how people interpret their lives. Join us in this session where Cat will do a short introduction on the topic, and after, we will talk about how this impact domain crunching. For instance, if we don't include software developers in requirements engineering, what is the impact? What if the software teams only allowed to build user stories and aren't part of the narrative for their building? And what about the exchange of narratives across the ecosystem, i.e. across domains. Do we have the hermeneutic resources to describe emergent behaviour across the system?