As a business, we want to make sure our software can handle changes when the business changes. We want to define boundaries that support the flow of the business value.

Within DDD we have the perspective of strategic design where we can split a large-system into multiple sub-domains, each having its purpose and responsibilities, where teams can work in autonomous, clean bounded contexts. One of the most effective ways to define these boundaries is by collaborative modelling with all the stakeholders involved in these domains. But that poses real challenges; What exactly is the definition of a (sub)domain? How can we form a common language of these boundaries? How does a customer journey fit in? And how do you decide and come to a single model in a large group, where everyone shares that same model on a high level?

Join Paul as he shares war stories about his experience doing collaborative modelling in several companies with 30+ people. He'll share our successes, but more importantly failures — and what he learned from them and share some distilled heuristics!

Writing CQRS/ES applications can be difficult, but maintaining them can be even more of a challenge.

The monitoring of the systems and the analysis of incidents are more complex operations in these contexts. During a debugging session, while trying to understand the flow of the process across multiple microservices, we may wonder: is it really worth it?

This talk aims to explore that question.

Whether starting a greenfield project or refactoring a Big Ball of Mud Monolith into Microservices, identifying domain boundaries early on in the design process will have a determinant impact on the shape of the resulting system and architecture, and is crucial to establishing the system's usefulness to different business stakeholders.

The problem is that there are many aspects to consider when it comes to design domain boundaries. They may be seen as multi-dimensional is some way. Consider for example some aspects such as knowledge scope, business capabilities, business processes, teams organization, different non-functional requirements. The right balance and tradeoffs have to be found in order to address them in a meaningful way for the business.

In this talk Tomasz explores different boundaries dimensions and their impact on the design of the software — whether it comes to greenfield or brownfield. Understanding different forces behind them will help you choose appropriate tactical tools and patterns when it comes to implementation.

Over her career, Jessica Kerr has taken part in many software communities: functional and object-oriented, agile and devops. Yet for her, the Domain Driven Design community is more important than any of these. It's because DDD (and its people) have long espoused the crucial aspects of all these paradigms. In this keynote, Jessica will point out the essences of other paradigms inside DDD, and the crucial part that the rest all miss.

Domain Driven Design and Messaging go hand in hand, like a warm chocolate brownie paired with vanilla ice-cream! DDD is a software discipline that allows you to move faster and write high-quality code. The whole point is to align the software you write to be flexible with the business changes. When you start to use the technology of messaging to communicate between clean and well-defined bounded contexts you get to remove temporal coupling. And voila, you now have microservices that are built for autonomy from the ground up. Sounds perfect?

In this talk, discover this intersection of DDD as a software discipline with messaging as a technology counterpart. Build reliable systems that can scale with the business changes.

Earlier this year Stefan Tilkov published a blog post entitled "Is Domain-driven Design overrated?"

Understandably it generated a lot of passionate responses online from some of the biggest names in the DDD community (a good many of whom are on the DDDx programme.)

Join us as we revisit this controversial-sounding question in this panel featuring Stefan, Susanne Kaiser and Marco Heimeshoff.

This is one session you do not want to miss!

Over the last 20 years, I've looked at a lot of legacy software to help development teams come to grips with the interwoven complexities. DDD has proven to be a very helpful method in this improvement work, although DDD was actually intended for the development of new software. With negative and positive examples, I will show the audience the simple steps they can take to transform their big ball of mud into a system that makes maintenance fun again. My greatest pleasure is to inspire the audience for DDD and good architecture.

DDD is about understanding and communicating complexity. We have long recognized that the most effective way to communicate complexity is via human language. But language poses a challenge when working in a team comprised of members of different (sub)cultures and nationalities, each with a native language that might not be the same as the language we are communicating in. Each of these cultures has a different perception about how to communicate effectively.

By way of example, in some cultures, it is considered appropriate and respectable to use the tentative voice “perhaps we should consider trying X”. Whereas in other cultures it is the assertive voice that is valued “This is how we should do it”.

Assuming that everybody in the room wants to communicate effectively, what aspects can we define that impact our design? What organizational culture fits better with what type of architecture (microservices, monolith)? And what cultural needs must these architectures and boundaries address to succeed? Join us in this interactive talk where we together explore these challenges!

The hexagonal architecture, or ports and adapters architecture, is an architectural pattern used for creating loosely coupled application components that can be easily connected to their software environment. This makes components exchangeable at any level, and facilitates test automation.

AWS Lambda provided the perfect environment to work with this architecture, moreover using hexagonal architecture, allows great flexibility to change the computational layer in case of porting across cloud services.

Today the software landscape of enterprise is not built ground up by scores of software developers. Software engineering skills are valuable and focus on the core domain of the business. For the rest, software is often purchased. Much of this software is commercial off the shelf (COTS) platforms that support many areas of the business. While these platforms perform critical functions such as managing our customer data, they are often treated as second-class citizens. Architects work around them.

It is becoming increasingly important for an architect to understand what are commercial platforms, best practices for managing them, and know techniques (such as DDD) that will help obtain most value. Join Sonya as she shares her extensive experience as a solutions architect in the world of commercial platforms and learn from a case study of how commercial platforms helped mass testing during Covid-19 pandemic.

No matter where you currently live, it is your home. Often people want more home than they currently have. More is for those with youthful vigor, the endlessly driven, the deserving, the best. As people grow older, is more what they want, or does wisdom suggest that less is better? Curious, these dynamics. When it comes to software development, what was your first "home"? Naturally when home hemmed you in, you wanted more. At what point did you want to "buy up" to more spacious compositions? What made you think that objects weren't doing enough and that you should start looking for a more functional home? At what point did you consider DDD and related tools to be the luxury you deserve? Are you there yet? If so, are you happy, or are you still moving up? Ah, moving up of course. But to what? What stands in your way of obtaining the very best of new digs, something more, you know, artificial? Here's the rub. No matter what, there will always be more, but at some point the previous might seem better. Where is this all leading, and will we ever be content with our spread? It depends. Let's examine trends, likes, dislikes, motives, and what might have real, lasting value.