The recent COVID-19 pandemic forced us DDD practitioners to move our collaborative modelling efforts to the remote world. Within collaborative modelling, we want to share all the information we have, all the different perceptions, even if they might look weird, quirky or invalid at the start. Only then can we design and create enriched models to build sustainable and valuable software. The problem here is, people will only share all their information if there is psychological safety, and that is already hard in a physical session, let alone remote.

Virtual Domain-driven design

Psychologic safety in remote collaboration with Gitte Klitgaard

There are many reasons to split up large-scale systems towards more modular, smaller services with their own model and language. You can decouple teams and give full autonomy of that service to a team. By decoupling services and teams you can handle changes to the domain faster, having a faster time to market. You decrease the cognitive load of the teams, empowering teams to truly understand the complexity of their shared models with domain experts. But how do we split up large-scale systems? What are the characteristics we can dissect a bounded context? How do we split towards a microservices architecture? We do not only have to deal with shifting terminology here but also different rates of change in the business. Join us in this Panel where we will hunt for design heuristics to split systems towards bounded contexts and microservices.

[Panel] Splitting systems towards bounded contexts and microservices

Just before all the holidays start we are closing this year 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 Ask us anything party! We have invited several people from the community who will join an online fishbowl in a zoom webinar. You post your questions and we will discuss them.

Domain-Drinking Dialogues - 2020 ending Ask us anything party

From twitter: https://twitter.com/mathiasverraes/status/1298665213978447873?s=20 Using collaborative modelling to build a shared understanding of your domain and use it to guide your design _is_ the philosophy behind DDD though. The rest is the principles, patterns, and practices. But perhaps just doing EventStorming does not actually make you a DDD'er, but what is? In today's panel, we will discuss with several people from the community what makes you a DDD'er? Joining us are: Emanuela Damiani Krisztina Hirth Mathias Verraes Jessica White Nick Tune

[Panel] What makes you a DDD'er?

There has been a lot of fuzz around the topic of test-driven development; some find it useful; some don't see any value in it. You also have different flavours like Detroit being inside-out, or London going from the outside-in. And then you have people saying TDD is about testing or is it a design tool? In this session, we will talk with Dave Farley about all these topics, and especially how to use TDD as a design tool. Dave Farley is well known in the software community, especially being the co-author of the continuous delivery book. He is also a firm believer that Test-driven development is one of the core principles to do proper continuous delivery.

TDD as a design tool with Dave Farley

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.

Remote facilitation with Kirsten Clacey, Jay-Allen Morris and Jo Perold

Too many products have been developed that serve one kind of client only. The reason is that the composition of the teams leads (subconsciously) to the development of products that serve only people that resemble the people in the team. One “famous” example is the soap dispenser that only works if your skin is white. If teams are really cross-functional and are resembling the diversity of the market, the products they’re creating are also better. Thus, if the whole team has the full business expertise, knows the market, reflects the full diversity of the clients, then it can even disrupt the market and isn’t waiting for some person (e.g. the Product Owner) to decide on priorities. With this real cross-functionality, the team can fully understand the company’s business and has a holistic view of it, knowing its contribution to the company’s value stream. Join us in a Panel dialogue with Jutta Eckstein and Maryse Meinen about that real cross-functional teams are an essential building block for implementing company-wide agility and the organization benefits by creating better and in a way more real products and by having more options when entering the war of talent.

[Panel] Design better products with real cross-functional teams - Jutta & Maryse

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!

[Panel] What can we learn from open-source with Matteo Collina

In the last meetup, Krisztina found something Jessica said interesting to dive into: "We are talking in DDD about Bounded Contexts and independent teams and applications, but then we all coupled by having the same user." That statement led to an exciting dialogue by inviting Dawn: "It is not so much coupling at the user as that sounds as if the user has to fit into what has built but starting with the user in the centre or intersection of the various "contexts". If your context no longer aligns with the user, who are you problem-solving/building the solution for?" Joining us with Krisztina, Jessica and Dawn will be Manuel from the Book team topologies, and together we will explore heuristics to organise teams, and their interaction and design bounded context for fast flow, which each serve the same customer.

[Panel] One user to bind them all? Products, teams and bounded contexts

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.

#DDDDD Panel: Natural Boundaries with Krisztina, Evelyn, Nick and Alberto

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.

Speaking truth to power: a foundational 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.

Balancing upfront design versus iterative design

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!

Virtual Lean Coffee Fishbowl: UX, DDD and BDD - take 2

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

#DDDDD: Bounded Contexts, Microservices, and Everything In Between

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.

[DDD London] DDD-Lite: Independent Service Heuristics with Matthew Skelton

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!

hubhopper

Psychologic safety in remote collaboration with Gitte Klitga...

hubhopper