by Virtual Domain-driven design
If you don't live near an active Domain Driven Design meetup, or just want to get more in-depth knowledge of DDD, please join this vast growing community! Anyone is invited here. We strive to create a community of like-minded people eager to dive more into Domain Driven Design. We are going to organise panel discussions, community talks and more. So feel free to join us!
Language
🇺🇲
Publishing Since
8/26/2019
Pitch yourself as a guest, propose sponsorships, or reach out directly to the host.
January 29, 2026
<p>In this session, we are joined by Rebecca Wirfs-Brock, who will first present a short talk on their essay <strong><a href="https://verraes.net/2022/09/critically-engaging-with-models/" rel="noopener noreferrer" target="_blank">Critically Engaging With Models</a></strong> followed by a group discussion. It would be great if you could read their essay beforehand. If you want to support their writing and read more, you can buy their book, <a href="https://leanpub.com/design-and-reality" rel="noopener noreferrer" target="_blank">Design and Reality: Essays on Software Design</a></p><p>Models, whether for a software system, a development process, diseases, political systems, or otherwise, are a way to look at (a part of) the world. They make a choice about what is important, what categories we classify things in, what we see, what’s invisible, what’s valued, or even what’s valid. They are reductionist, that is, they only show a selection of the subject they’re describing. And they are biased: They implicitly reflect the assumptions, constraints, and values of the model’s author. Most of the time, when you adopt a model created by someone else, you assimilate it into your world view without much thought. You acquire a new way of seeing something. But when you do that, you may not understand the model’s limitations. However, you can choose to look at someone’s model more intentionally. We will share and discuss some tools for critically evaluating any models that come your way. You can assess whether this model fits your needs. If you’re looking at a model for the first time, you can use that fresh perspective to see what the model includes and what it leaves out. Models are a powerful lens for perceiving a subject, and you should be deliberate when wielding them.</p>
November 26, 2025
<p>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.</p><p>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.</p><p>We’re happy to share the insights gained and challenges remaining in a conversation with VirtualDDD.</p><h3>About the speakers</h3><p><strong>Seb</strong> 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.</p><p>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.</p><p>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).</p><p>He blogs at <a href="http://claysnow.co.uk/" rel="noopener noreferrer" target="_blank">claysnow.co.uk</a> and socialises as sebrose@mastodon.scot</p><p>Gá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).</p>
November 7, 2025
<p>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.</p><p>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.</p><p><br></p><p>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.</p><p><br></p><p>This is an introduction to systems thinking and its importance when dealing with complexity.</p><p><br></p><p><strong>About Trond</strong></p><p><br></p><p>Senior IT Consultant and sociotechnical practitioner.</p><p><br></p><p>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.</p>
Have a different question and can't find the answer you're looking for? Reach out to our support team by sending us an email and we'll get back to you as soon as we can.
If you don't live near an active Domain Driven Design meetup, or just want to get more in-depth knowledge of DDD, please join this vast growing community! Anyone is invited here.
We strive to create a community of like-minded people eager to dive more into Domain Driven Design. We are going to organise panel discussions, community talks and more. So feel free to join us!
This podcast updates weekly.
This podcast is available on 10 platforms including Apple Podcasts, Spotify, and more. You can also use the RSS feed directly.
Yes, this podcast regularly features guests.
Pod Engine is not affiliated with, endorsed by, or officially connected with any of the podcasts displayed on this platform. We operate independently as a podcast discovery and analytics service.
All podcast artwork, thumbnails, and content displayed on this page are the property of their respective owners and are protected by applicable copyright laws. This includes, but is not limited to, podcast cover art, episode artwork, show descriptions, episode titles, transcripts, audio snippets, and any other content originating from the podcast creators or their licensors.
We display this content under fair use principles and/or implied license for the purpose of podcast discovery, information, and commentary. We make no claim of ownership over any podcast content, artwork, or related materials shown on this platform. All trademarks, service marks, and trade names are the property of their respective owners.
While we strive to ensure all content usage is properly authorized, if you are a rights holder and believe your content is being used inappropriately or without proper authorization, please contact us immediately at hey@podengine.ai for prompt review and appropriate action, which may include content removal or proper attribution.
By accessing and using this platform, you acknowledge and agree to respect all applicable copyright laws and intellectual property rights of content owners. Any unauthorized reproduction, distribution, or commercial use of the content displayed on this platform is strictly prohibited.