Virtual Domain-driven design

Collaboration in remote meetings doesn’t have to be difficult, learn how to make it effective, enjoyable and valuable. Join us for a panel discussion and see how we as a DDD community can improve our remote collaborative modelling sessions from Kirsten Clacey and Jay-Allen Morris, authors of The Remote Facilitator’s Pocket Guide and Jo Perold Coach and Trainer at Agile42 & keynote speaker at conferences.

Design experts Jutta & Maryse discuss the importance of real cross-functional teams in product development. They highlight how team diversity leads to better products, avoiding biases like a soap dispenser that only works on white skin. They emphasize the benefits of inclusive team composition, distributed leadership dynamics, knowledge sharing, and the power of diverse perspectives in enhancing team capabilities and organizational goals.

Thanks to Krisztina we will have Matteo Collina as a special guest on our next panel. Matteo is a long time Nodejs contributor and TSC member. Open-source software is a success story, and undoubtedly one, we can learn from. In OSS the clocks tick differently, but it is software built for users, to solve problems - both relatively unknowns factors at the beginning. So what can DDD developers for businesses learn from that experience: how to handle these uncertainties, how is the Ubiquitous Language developed in the Open source world? How do you do design in OSS? And many more questions!

The podcast delves into the concept of bounded contexts and the challenge of maintaining autonomy for different teams while serving the same user. It also explores the importance of brand consistency and understanding user journeys. The distinction between UI and UX is discussed, as well as the significance of shared motivation and goals within a team.

Finding the right boundaries of contexts is hard - implementing them can be even harder if the organisation does not change. But how can one change the organisation, how can one be sure that it changes in the right direction? There are signs, mostly perceived as a blocker but I see them as an enabler, as a pointer to the right boundaries. This idea combined with observing and measuring the value stream could lead to the right boundaries for teams and for code.

As complexity increases, are you (too often) shouting into the wind? Do you see icebergs ahead yet fail to convince others to avoid them? Are your architecture-focused discussions more exhausting than productive? Does the accountant understand the value of your work? The thinking and communication skills we've developed on the job often fail us when we face more-complex challenges. That is why we are learning DDD. Rather than double down on code-specific solutions, we are developing different, more effective conceptual approaches. Yet, there is an underlying skillset the nourishes and supports our ability to practice DDD or any approach that challenges traditional "power" structures. In this workshop, we'll focus on that skillset.

We want early feedback to inform foundational or load-bearing decision making before committing to hard/expensive to change design decisions. But we don’t want to start building based on flawed design decisions, the consequences of which are hard/expensive to change when we discover it is faulty. The problem is, how do we balance these two polarities from an either-or to both-and thinking. In this session, we will explore contexts and tradeoffs in upfront design versus iterative design. Joining us to share their perspectives and experiences in a never-ending discussion are: *Dawn Ahukanna (Design Principal and Front-End Architect) *Rebecca Wirfs-Brock (Architecture, Design Heuristics, and Agile Practices) *Diana Montalion (Architecting content systems strategies for enterprise) *Vladik Khononov (Software Engineer and Cloud Architect) and *Trond Hjorteland (IT Architect and aspiring sociotechnical systems designer). We will facilitate using a polarity map from Barry Johnson to guide the conversation and find out the patterns and signs to observe to start managing these polarities for yourselves.

It all started with a tweet by John Cutler "Wonder how many BBD / DDD enthusiasts are aware of the body of similar work in #ux research and vica versa". And it seemed that a lot of people from these communities learned a lot from each other. And we would love to learn more about different areas of overlap. It seems like goals and culture are aligned in both communities. Join us in our second Virtual Lean Coffee, where a panel of around 15 people from the UX, DDD and BDD community will exchange topics that overlap with each community. The great thing is, you can participate because we are making the Lean Coffee a fishbowl! Join zoom and join us live in the discussion, or just sit back and enjoy the stream from youtube and ask questions in the chat! Hope to see you there!

“95% of the words are spent extolling the benefits of ‘modularity’ and that little, if anything, is said about how to achieve it” - Glenford J. Myers, 1978. This quote is 40 years old. Today, 4 decades later, nothing has changed except terminology. Time to change this. I want to talk about the various strategies of decomposing systems into modular components. You will learn what exactly Bounded Contexts and Microservices are, and what are the differences between the two notions. We will analyze what happens between services - how data flows, and how these flows can be optimized. Ultimately, we will explore different decomposition strategies and heuristics for designing modular systems - systems that aren’t driven by ever-changing fads, but by your business needs.

When designing organizations for fast flow of change, we need to find effective boundaries between different streams of change. Techniques like Domain-Driven Design (DDD) are very powerful for this but can be quite involved and difficult to learn. A lightweight intermediate approach is to ask "could this thing be run as a cloud-hosted (SaaS) service or product?". This session explores the Independent Service Heuristics, a kind of “DDD-Lite” approach based on some ideas in the book Team Topologies by Matthew Skelton and Manuel Pais. The Independent Service Heuristics help teams to find candidate services and domains for running as a separate value stream or separate service. The Independent Service Heuristics have proven useful for various organizations improving flow. In this session, we would really welcome feedback and critique of the approach. Where might the approach not work? What pitfalls might there be? Are there questions or material missing? See the Independent Service Heuristics on GitHub at https://github.com/TeamTopologies/Independent-Service-Heuristics - send a Pull Request! The material is Creative Commons CC BY-SA.