Virtual Domain-Driven Design

Virtual Domain-Driven Design

@virtualddd.com

A community driven platform for people who want to get more in depth knowledge of Domain-Driven Design and solving complex business problems.

402 followers41 following162 posts

One person's holiday laptop full of scripts turned into 200 "custom" reports (really 5 templates in disguise). @kathrynhempstalk shared how getting data out was never designed for — and cost… Read, watch, or listen: buff.ly/Xl58fZe

virtualddd.comGetting Data Out: The Requirement Nobody Designed ForGetting data out of an application is a first-class design problem. Learn how one team replaced 200 hand-copied scripts with templates, and what it cost.
View full thread

We started Virtual DDD in 2019 for people who didn't live near a meetup and wanted to go deeper than a conference talk allows. Seven years on the goal is the same. Work out what DDD actually is, in the open, and keep track of how it keeps evolving.

Hand a vague instruction to a person and you get a question back. Hand it to an agent and it picks an interpretation and runs with it. Well structured code, solving something nobody asked for. Typing speed was never the bottleneck. Meaning was.

There is a version of career progression that looks like success from the outside and feels like a slow erosion from the inside. You attend more meetings, write less software, and someone asks if you'd like to become an architect. Read, Listen or Watch the full story by Larissa here: buff.ly/99BtmNJ

Architects often start enthusiastic and end up worn down by the gap between vision and what systems allow. Larisa Feldman spent years watching this happen before reluctantly stepping into the role herself. Read, watch, or listen: buff.ly/wg1Inqg

buff.lyThe Reluctant Architect: A Career Path Nobody PlansLarisa Feldman spent years watching architects lose their spark—then became a reluctant architect herself. On why good architecture serves engineers.

It's hard when teams identify problems as technical, but the real issues are deeper. We interviewed nine practicioners at @dddeu.bsky.social and ask them: what's the hardest part of facilitating software architecture and design? Read, watch, or listen: buff.ly/urFrFzD

buff.lyWhen the Problem Isn't Technical: 9 Voices from DDD EuropeAt DDD Europe, nine practitioners agreed the problem isn't technical. Discover why facilitation, power structures, and the right people decide outcomes.

We've all been in that meeting. Someone senior has already decided on a solution — maybe they read something, maybe a vendor pitched it to them — and now the conversation isn't really about the problem anymore. Read, Watch, Listen to Kim who shares how he dealt with this situation: buff.ly/xJVD0Hv

There are many architecture workshops that help you figure out which bite-sized microservices you should extract from monoliths. But with everything else, you need to understand what it is you're working with before you start working with it. Check Aino Vonge Corry full story here: buff.ly/PQOgn3z

It's hard when architects assume they share a system's structure. Aino (Cornils) Vonge Corry shared a story about asking a team to draw their monolith & realizing everyone saw something different. Read, watch, or listen: buff.ly/PQOgn3z

buff.lyWhy Drawing the Same System Reveals Different ArchitecturesWhat happens when architects draw the same system and get different diagrams? Learn how externalising mental models transforms architecture discussions and reveals hidden disagreements.

It's tough when a major outage demands centralized control, but the true fix comes from an unexpected place. @lizthegrey.com shared a story where psychological safety allowed an engineer to surface the solution. Read, watch, or listen: buff.ly/e05CGau

buff.lyStaying Out of the Way: Incident Command & Psychological SafetyWhen a Google Cloud outage was fixed by someone no one paged, the real lesson was psychological safety. Learn how Liz Fong-Jones built resilient teams.