Virtual Domain-driven design

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

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.

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.

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.

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.

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!

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.

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.

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?

Getting started or advancing your Domain-Driven Design knowledge on your own can be a frustrating experience. Especially when you have so many questions to ask and exciting domains to model. How do you then grow if there is no one in your company or area that shares your passion for DDD? During this Virtual DDD meetup Zsofia and Kacper will share their experiences in building communities in Hungary and London. They will discuss on topics such as finding speakers, venues, managing attendance and how to deal with no-shows. You will have an opportunity to join in and ask questions that we can crunch further. Let’s make it easier to start an own meetup group and try to figure out together how to grow as a domain modeller and meetup organiser.

Even with perfect naming and perfect code, it is hard to read the story of your domain straight out of it. You can be certain that you’ll have forgotten some of the nuances about the code the next time you see it. Or someone else sees it, because very few of us live our professional coding lives in an area where it’s only me ever handling the code. Someone is going to come back to your code - in five days, three months or five years. Luckily, if you write your tests the right way, they can tell the story of your domain in a way your production code can't. Let us show you how to create your tests so you can get rid of your stale documentation.

Within the community, there is been an ongoing discussion about the aggregate pattern. From Eric Evans perspective it is:

An architectural pattern that enforces the consistency of a set of interrelated constraints, by defining a transactional boundary, a concurrency boundary, and a distribution boundary.

A lot of people seem to have different perceptions, different explanations or altogether don't think we need to use the pattern. In this #VDDD meetup, Thomas Ploch will tell us his vision and after we will open the dialogue and try to make more explicit: What is an aggregate and how do we teach this to other people.

In the next SunDDDay discussion Alexey Zimarev and Marco Heimeshoff will join us and share their experience in building systems with CQRS and Event Sourcing. We will discuss what it exactly is, where it came from, what the strength and weaknesses are, when and how to use it, and how to design and maintain these systems. Join us through zoom webinar or follow the live youtube stream. You can interact with us and ask your questions through chat, or raise your hand in the zoom webinar and join us live to ask your questions fishbowl style!

Rebecca Wirfs-Brock, Paul Rayner en Alberto Brandolini will join us in this VDDD meetup and talk about what types of EventStorming there are, and what heuristics they use. Join us through youtube or zoom webinar in this discussion. You can interact with us and ask your questions through chat, or raise your hand in the zoom webinar and join us live to ask your questions fishbowl style!

On this first SunDDDay 26th May at 16:30 Central European Time (Amsterdam GMT +2), virtual DDD meetup will hold an online panel discussion where you can ask questions! Marco Heimeshoff, and Kenny baas-Schwegler (with a possible attendance by Zsófia Herendi and Trond Hjorteland) will discuss their experience with EventStorming and User story mapping for domain discovery. The two main questions are: * How can we best combine User Story Mapping and EventStorming for domain discovery. * How can we go from EventStorming to user stories.

DDD is about enabling developers and business owners to work together on a collaborative model, but how do you introduce the concept? In a world rife with acronyms and buzzword, people can be hesitant to try out new ideas, especially ones that involve changing the status quo. In this session, we'll discuss various techniques and ideas for introducing DDD to an organisation, with a focus on the needs of the company and individuals, and how to approach those needs. Afterwards, you'll be better able to demonstrate the value of DDD to stakeholders, without scaring them off with a load of new jargon. Join us in this conversation with Barry O Sullivan. You can join the conversation through zoom webinar fishbowl style asking questions live. Alternatively, you can always ask questions through the chat on zoom or youtube or just sit back and relax and watch the youtube stream!

In this SPA conference special, we will talk with Trond Hjorteland about if business capabilities are useful in DDD.

The DDD community seems to consist of mostly technical people, or at least with some sort of hands-on programming experience, both now an back when the blue book was published. The decision to put the technical patterns at the start of that book was strategic (!) in that it was meant to invite the programmers in. As a consequence of that, it seems that most know very little about the enterprises' architecture space, and if they do, it seems to be with disdain for those dreaded ivory architects. And, for good reason in a lot of large waterfall-driven enterprises.

My thesis is that by this approach we as a community is throwing the baby out with the bathwater, at least some parts. There are things we ought to take a look at and incorporate into our toolbox, like architectural principles and business capabilities. The latter has been something I have had a special keen interest for, coming from the SOA space, and see a lot of parallels with the strategic patterns in DDD. I even believe it can be a great technique for getting started with discovering the problem space and even guide defining the bounded contexts.

I would love to have a good discussion on this and maybe we all can gain some new insights. That is always good, right?

In this next virtual DDD meetup, João Rosa and Krisztina Hirth will discuss with us how impact mapping helps to find the possible solutions to achieve a measurable goal before you even know what to visualize. Also, how can you then combine it with other visualisation tools like EventStorming to guide your strategic design?

In our industry, we have been assisting in digital transformations; the digital transformations have different labels, DevOps, Agile, Cloud, amongst others. However, most of these transformations just following a script, applying the same recipe everywhere. This approach has its merits, but also its pitfalls.

To balance the change, visualisation techniques can be applied, aiding people, teams and organisations to manage the change and guide strategic design.

See more info at https://www.impactmapping.org

Notes from the speakers: Good metrics are very important. What contains a metric: What to measure ('time to deliver') How to measure('nr.of days') What is the current situation ('benchmark') Minimum acceptable value for the investment ('constraint') Desired value ('target')

Do not try to define everything but build - measure - learn Use the metrics to decide about the next iteration

the bottom line would be: read the book and start with yourself: ask yourself if you deliver a business goal or just some lines of code which could help or not.

In this # VDDD meetup, we will talk with Ora Egozi-Barzilai and Evelyn van Kelle about their experience with socio-technical architecture. Socio-technical refers to the interrelatedness of social and technical aspects of an organization. Specific for this meetup we will discuss how teams affect the boundaries between bounded contexts and vice versa. These effects will give challenges in the way we design software architecture and organize teams around software to be highly aligned with business goals.

Over more than 15 years ago, Eric Evans published the book Domain-Driven Design. The blue book, as it is called today, has a vast amount of knowledge on software architecture. As Paul Rayner once stated 'Every new idea on software architecture; you can already find somewhere in the blue book'. Because the knowledge is so fast to take in at one go, a lot of people who bought the book never finished the book, mostly stopped reading before Part IV, strategic design. Therefore in this #VDDD special 'How to read the blue book,' Mathias Verraes will discuss with the strategic parts.