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

Behaviour Driven Development (BDD) is a term that was coined by Dan North in 2006. It came about as a response to a very specific problem – teaching developers how to think about testing their code. It incorporates the ubiquitous language idea from Eric Evan’s book Domain-Driven Design, and this evolved into a technique used by the whole team to collaboratively specify how the finished system should behave. While both approaches focus on collaboration, DDD focuses on a shared model for building software and BDD focusses on specifying the behaviour of the system. So what can we learn from both our techniques? Join us in this session were Seb Rose, Steve Tooke and Matt Wynne will discuss with us how we can improve modelling with BDD. We will bust popular BDD myths and talk about their favourite collaboration techniques.

The power of collaborative modelling comes from having a diverse group of people who, together, have a lot of wisdom and knowledge. You would expect that all this knowledge will be put to use, co-creating, and to design a model. In reality, we don’t actually listen to all the available input and perspectives due to cognitive biases and ranking. Good modelling needs all the insights and perception to design the best one. If you are not aware, cognitive biases and ranking kills those insights and kills the effectiveness of your models! Join us in this session talking with Evelyn van Kelle, Romeu Moura and Vanessa Schwegler about how awareness of your own cognitive biases and your ranking in the group can create more effective models! We will discuss how to use biases and ranking in your favour, making sure people are not excluded, and every knowledge is rally heard and put to good use in your models!

Let's talk about the confluence between domain-driven design and security. Deep understanding of the domain lets us define what we DO want to happen, which helps us stop things that we DON'T want to happen. Jessica Kerr will start the meeting up with an exposition of her favorite parts of the book Secure By Design and together with Dan Bergh Johnsson and Daniel Deogun we will do a panel discussion and Q&A. Come add your perspective at the Virtual DDD meetup.

Language is a big topic in the Domain-Driven Design community. We want to have small bounded contexts, each with there own ubiquitous language. Having many ubiquitous languages means having a lot of translation between the bounded context. And having many translations means we can get lost. So what is the nuance between internal and external bounded context or services translation? Join us in a conversation with Julie Lerman, Indu Alagarsamy, Michael Plod and Nick Tune to talk about these nuances. We will talk about all the concept of dealing with these translations. From Anti-corruption, interchange, gateway, upcasting events plus the relationship patterns like the conformist, partnership and newer patterns.

It all started with a tweet by John Cutler . 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.

Feature branching is again gaining in popularity due to the rise of distributed version control systems. Although branch creation has become very easy, it comes with a specific cost. Long living branches break the flow of the software delivery process, impacting throughput and stability, but does it also affect the quality of our domain model? Join us with Thierry de Pauw in this Virtual DDD sessions to explore with us how feature branching can impact domain-driven design. Because one of the critical aspects of DDD is to keep gaining new insights together to create a rich and rigid domain model. For this, we need fast feedback which could be disabled by feature branching.

For the past decade and a half, Domain-Driven Design has been giving teams the tools to successfully tackle the complexity at the heart of software. But lots of people fail when they try to put its techniques and patterns into practise, especially at scale. Why? It can't just be because the Bluebook is so thick? We're going to argue that the "near enemies" of DDD are to blame. Things which look like DDD, but which are in fact counterfeits that push us farther away from our goal. Join us with Gayathri and Andrew who will tell the story of a large-scale DDD implementation that got complicated. They'll talk about how took stock of the situation as they found it, how they identified where the root problems lay, how they set everyone off on a course of success, and the mistakes we made along the way. Regardless of whether you are working with serverless, microservices or a more monolithic architecture (nothing wrong there!) - this fun talk is for those who want to learn the lessons of implementing DDD at scale, with a healthy dose of pitfalls and hazards to watch out for too

On twitter, a discussion started between Trond, Anton and Krisztina about working in agile product development without a clear business goal. Since twitter is a restricted medium to discuss these issues, we are taking it upon our VirtualDDD Meetup. Join us with Trond, Anton and Krisztina and let's have an honest discussion about what it means to work agile. What are the pros and cons? We dig into the underlying principles and philosophy of agile, diving into the practical instead of the theoretics of business agility. Do we need the business to be agile to do proper Domain-driven design, and what are the overlaps between agile and Domain-driven design?