On this site, there is only displayed the English speaking sessions of the OOP 2022 Digital. You can find all conference sessions, including the German speaking ones, here.
The times given in the conference program of OOP 2022 Digital correspond to Central European Time (CET).
By clicking on "EVENT MERKEN" within the lecture descriptions you can arrange your own schedule. You can view your schedule at any time using the icon in the upper right corner.
Thema: Domain-Driven Design
- Artificial Intelligence Now!
- C++ and Programming of Embedded Systems
- DevOps & Automation Now!
- Diversity & Inclusion
- From Projects to Products/Services: Aligning Architecture and Organization for Sustainable Speed
- Full Day Tutorial
- Fusion: IT-Future-Society
- Half Day Tutorial
- Modern Software Architecture
- Product Development in Times of Digitalization
- Signature Track: The Time is Now!
- Social Integration
- Software Architecture Communication & Assessment
- Testing & Quality
- Trends & Techniques
- Use Domain-Driven Design Now!
- Artificial Intelligence
- Domain-Driven Design
- Product Development
- Programming Languages
- Requirements Engineering
- Soft Skills/Social Skills
- Software Engineering
- Talks with Limited Attendance
- Testing & Quality
- Virtual Reality
After two decades of being a business software developer, a DDD consultant and an Event Storming aficionado, I started to build a game and had no clue how to.
So I modelled the heck out of the game using Event Storming and implemented it using all the DDD patterns, functional and object oriented architecture patterns and even CQRS & Event Sourcing.
Let me show you how much fun it is to build a game, using everything you know about business software and subsequently, how your business software building abilities will improve from building games.
Target Audience: Senior Developers, DDD Enthusiasts, Game Developers, Software Architects
Prerequisites: The will to put the fun back into functioning business software
In a world of rapid changes and increasing uncertainties, organizations have to continuously adapt and evolve to remain competitive and excel in the market. In such a dynamic business landscape organizations need to design for adaptability. Designing for adaptability requires understanding the landscape organizations are operating in, identifying patterns of change, applying principles for organizational fitness, and making mindful strategic decisions to adapt change.
Target Audience: Software Architects, Tech Leads, Engineering Manager, VP of Engineering
Organizations need to aim for building systems and team organizations aligned to the business needs and business strategy and evolving them for adaptability to new changes and unknown environments.
This talk brings different perspectives and techniques together from business strategy (Wardley Mapping), software architecture (Domain-Driven Design), and team organization (Team Topologies) as a powerful toolset to design, build and evolve adaptive systems and team structures for a fast flow of change.
The world in which a software system lives is filled with meaning. The structure, concepts and names that inform the code, its changes and the mental models held by developers are expressions of meaning. The very act of development is an exercise in meaning — it's discovery, its formulation, its communication.
But just because we are immersed in concepts of meaning from an early age, and just because the daily work of software development is about wrangling meaning, that doesn't mean we're necessarily good at it. Let's talk about what we mean.
Target Audience: Developers, Architects, UX, Product Owners
Prerequisites: No specific prerequisites
"It's just semantics." How many conversations about philosophy, politics and programming are derailed by this thought-stopping comment?
Semantics is all about meaning. If there is one thing we struggle with and need to get better at, it is the search for and clarification of meaning. The world in which a software system lives is filled with meaning. The structure, concepts and names that inform the code, its changes and the mental models held by developers are expressions of meaning. The very act of development is an exercise in meaning — it's discovery, its formulation, its communication. Paradigms, processes and practices are anchored in different ways of thinking about and arriving at meaning.
But just because we are immersed in concepts of meaning from an early age, and just because the daily work of software development is about wrangling meaning, and just because it's just semantics, that doesn't mean we're necessarily good at it. It takes effort and insight. Let's talk about what we mean.
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. Join us were we share war stories about our experience doing collaborative modelling in several companies with 30+ people.
Target Audience: Architects, Manager, Decision Makers, Tech Leads
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 Domain-Driven Design we have the perspective of strategic design. A perspective where we can split a large-system into multiple sub-domains, each having its purpose and responsibilities. Within these sub-domains, 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? What is problem space? 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 us in this talk where we will show and tell war stories about our experience of having done collaborative modelling in several companies. We will tell our successes, but more importantly our failures and what we learned from them. What are the key heuristics we think that makes a collaborative modelling session with 30+ people, without any DDD knowledge, succeed? What are the skills we need to learn to facilitate it, and how can we make a company not dependent on us as consultants to continue their journey? You will leave with the knowledge of how to start your own collaborative modelling of your domain boundaries. We tell you our definition of (sub)domains, problems and solution space, and how we explained it to the companies we consulted. Providing you with new perspectives on how to embed this as a ritual in your company.
If we want to make sustainable design decisions for our architecture that are embraced by everyone, the most effective way is to do this collaboratively. It is hard to do because we need to deal with all sorts of group dynamics that cause people to stop sharing what they want, ending up in resistance behaviour from sarcastic jokes, to stopped communication. So how can we make collaborative design decisions better? Join us in this hands-on workshop where we explore different models of decision making.
Maximum number of participants: 24
Target Audience: Architects, Managers, Decision Makers
If we want to make sustainable design decisions for our architecture that are embraced by everyone, the most effective way is to do this collaboratively. Everyone can feel a part of the decision, and can potentially give the input they have. The group is aligned and knows what is to be expected onward. On paper this sounds great, but in reality we know it is hard to do because we need to deal with all sorts of group dynamics. Dynamics like cultural differences, conflicts of opinions, cognitive biases, and polarities that the group are part of. These dynamics cause people to stop sharing what they want, which ends up in resistance behaviour from sarcastic jokes, to stopped communication or leaving the session. No wonder a lot of people resort to a more autocratic form of decision making, where the architect analyzes and makes the decision. So how can we make collaborative design decisions better?
Join Gien, Evelyn and Kenny in this hands-on workshop where we explore different models of decision making that can help facilitate collaborative design decisions. We will dive into a variety of facilitation techniques such as:
- Working with climate reports to trigger hidden group conflicts
- Visualising trade-offs of different models with the pro-con-fix list
- Taking group decisions with full buy in with Deep Democracy