On this page you will only see the English-language presentations of the conference. You can find all conference sessions, including the German speaking ones, here.
The times given in the conference program of OOP 2024 correspond to Central European Time (CET).
By clicking on "VORTRAG 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.
Track: Domain-Driven Design expands our horizons
- Architecture – for Humans?
- C++ and possible Alternatives
- Domain-Driven Design expands our horizons
- Embedding AI into your Products: Practical Applications of Foundation Models
- Full Day Tutorial
- Half Day Tutorial
- Shaping the future: Overcoming Boundaries with New Ideas in Product Ownership, UX & Requirement Engineering
- Social Integration
- Software Architecture – Systematically Handling Quality Attributes
- Special Event
- Testing & Quality
- Thinking DevOps further
- Trends & Techniques
When Eric Evans wrote the Blue Book, he could not have foreseen cloud computing, infrastructure as code, and managed services.
Many of his tactical DDD patterns seem inadequate and strangely misplaced in cloud native environments. Even microservices, strongly tied to bounded contexts, no longer seem inevitable, as the industry standard shifts to serverless, low-/no-code tools, and genAI.
How much of DDD is still relevant? Can the same heuristics guide us through a different landscape? A story about finding boundaries in a strange new world.
Target Audience: Architects, System Designers, Developers with intermediate experience
Prerequisites: No previous cloud skills required, but helpful
Tobias Goeschel started his career as a freelance web developer in the late 90s and has since worked on hundreds of projects of varying sizes and lengths - from a single person to multiple teams, from a few days to several years - and in many different roles: Consultant, crafter, coach, and... well, architect. He is a strong advocate of diversity and inclusion in the tech industry, and an active member of the European Software Crafters and Domain Driven Design communities.
Domain-driven Design (DDD) steht für eine Vielzahl an Techniken wie strategisches DDD, taktisches DDD und kollaborative Modellierung. Dieser Vortrag gibt einen Überblick über das DDD-Universum. Dabei stellt er nicht nur die verschiedenen Konzept vor. Er zeigt außerdem auch die jeweiligen Vor- und Nachteile der Praktiken auf und weist auf die typischen Fallstricke hin - und wie man sie vermeiden kann.
Zielpublikum: an Software-Architektur Interessierte
Voraussetzungen: Grundlegendes Verständnis von DDD
Mehr Inhalte dieses Speakers? Schaut doch mal bei sigs.de vorbei: https://www.sigs.de/autor/eberhard.wolff
Eberhard Wolff ist Head of Architecture bei SWAGLab und arbeitet seit mehr als zwanzig Jahren als Architekt und Berater, oft an der Schnittstelle zwischen Business und Technologie. Er ist Autor zahlreicher Artikel und Bücher, u.a. zu Microservices, und trägt regelmäßig als Sprecher auf internationalen Konferenzen vor. Sein technologischer Schwerpunkt sind moderne Architektur- und Entwicklungsansätze wie Cloud, Domain-driven Design und Microservices.
Xin has lived and breathed DDD for more than a decade. Drawing on her experiences, Xin makes a case for DDD’s rising relevance in a post-modern world, where aging companies struggle with aging software, while adding new software and complexity to their IT portfolio. With good attractor effect DDD is evolving from a software-centric design discipline to a multi-dimensional toolbox. Join Xin to reflect together on, how DDD can help us sustain meaning and productivity in a reality of vast sociotechnical complexity and constant change.
Target Audience: Software Professionals, Architects, Leaders, Agile Practitioners, Change Agents, Facilitators
Prerequisites: Basic DDD understanding; Prior DDD experience is not a must but helps understand the deeper message
What is the first thing that comes to mind when you hear the word DDD – Domain-Driven Design? The geeky technical patterns (Value object, Entity, Aggregate, etc.)? Walls decorated with colorful event storming stickies? A miracle cure to rescue change initiatives in large companies? Or are you thinking of a software development method born in the pre-cloud and pre-microservice era, which after 20 years is still struggling to gain traction?
Xin has lived and breathed DDD for more than a decade. In this talk, Xin makes a case for DDD’s rising relevance in a post-modern world, where aging companies struggle with aging software, while adding new software and complexity to their IT portfolio. The reflections will be grounded in solid DDD experiences and observations from the battlefield. With good attractor effect DDD can evolve from a software-centric design discipline to a multi-dimensional toolbox of thinking, modeling and collaboration techniques. You will be invited to explore DDD's value proposition and reflect upon how to leverage DDD’s strategic and tactical design approaches in your own context.
Globally, there is an increasing interest in DDD. Hope is evergreen for DDD to become a key ingredient in the magic potion for tackling the increasing complexity, not only at the heart of software, but also at the heart of sociotechnical organizations. How can DDD help us create meaning and productivity in a reality of multi-dimensional complexity and constant change? What’s in it for me? What’s in it for us?
Xin Yao is a sociotechnical architect, DDD evangelist and independent consultant. She believes that a product, domain and team-oriented architecture is the super glue to bind multiple agile teams navigating toward a common horizon. She’s spearheaded large-scale change initiatives in boundary-spanning architect roles, weaving together strategy, products, teams, systems, domains into coherent models to guide progress and reduce stress. She architects collective experiences in scale-ups and enterprises to unravel complexity and discover leverage points. In sociotechnical environments where a team’s cognitive capacity is under constant stress, she practices domain-driven design and facilitates collaborative modeling to help teams and organizations make sense, make decisions and make intuitive business software.
In a microservices architecture, services shall be as loosely coupled as possible. Still, they need to communicate with each other in order to fulfill business requirements. Now there are so many questions around this communication (synchronous vs asynchronous, event-driven? what is the influence on the coupling of your services? ...?). This talk will help you answer these questions for your project. You will better understand not only the architectural implications but also the effect on the productivity of your teams.
Target Audience: Architects, Engineers, Developers
Prerequisites: Basic experience with distributed systems
In a microservices architecture, services shall be as loosely coupled as possible. Still, they need to communicate with each other in order to fulfill business requirements. Now there are so many questions around this communication:
- What are the general possibilities to communicate? For example synchronous, asynchronous, or event-driven communication. What are the tradeoffs and which communication style should you prefer?
- What is the influence on the coupling of your services? For example, asynchronous communication reduces temporal coupling between services.
- What do I have to consider when selecting a certain communication style? For example, you need to apply certain resilience patterns if you want to use synchronous communication.
This talk will help you answer these questions for your project. You will better understand not only the architectural implications but also the effect on the productivity of your teams.
Mehr Inhalte dieses Speakers? Schaut doch mal bei sigs.de vorbei: https://www.sigs.de/autor/bernd.ruecker
Bernd Rücker is a software developer at heart who has been innovating process automation deployed in highly scalable and agile environments of industry leaders such as T-Mobile, Lufthansa, ING, and Atlassian. He contributed to various open-source workflow engines for more than 15 years and is the Co-Founder and Chief Technologist of Camunda – an open-source software company reinventing process automation. He is the author of "Practical Process Automation" and co-author of "Real-Life BPMN". Additionally, he is a regular speaker at conferences around the world and a frequent contributor to several technology publications. He focuses on new process automation paradigms that fit into modern architectures around distributed systems, microservices, domain-driven design, event-driven architecture, and reactive systems.
**TL, DR;** Embrace no-code to explore more models and throw most of those models away. You will quickly discover what works, and what matters, in the business process that you are automating. If it matters enough, you can extract it into a high-fidelity design in code.
Target Audience: Everyone with a stake in the software production process
Many software projects still consume considerable resources, and take a long time before anything material is put in the hands of the end-user. At a smaller scale this happens with teams that have the ambition to adopt Domain-Driven Design principles but that lack the expertise and experience in how to approach the design process. There is a spectrum of mistakes. On one hand there is the lack of producing a meaningful and shared model that is able to unify the conflicts and handle the complexity that the messy world will serve the system. On the other end of that spectrum there is analysis paralysis: a model that never sees the light of day, because there is always a new case it cannot handle. If the team doesn't produce a meaningful model, or if it fails to put that model in front of experts early on, then the team robs itself of precious feedback. "Judge models by their usefulness" is a mantra that is difficult to live by, if the model isn't being used...
Despite warnings, teams design big architectures early on, to support even bigger ambitions of the organization they work for, but they forget that it's not the architecture that the end-user cares about. With every bit of structure that is added early on, the team reduces the degrees of freedom to evolve the system at a later point in time. In order to support long-lasting design that is attuned to the environment, teams should set architectural principles that allow for a helpful structure to emerge, regardless of the platform.
> **No code** has entered the chat...
For a while now, no-code vendors have been telling organizations that they shouldn't be limited by expensive software engineers to build systems that are useful. No-code aims to commoditize the software production process. Commodification of technology leads to value if it removes a limitation, but successful adoption only works if the rules and policies that initially helped us overcome the limitation are replaced as well. Practices such as DevOps have to be adopted in order to reap the benefits of the commodification of compute and storage in the cloud. In order to benefit from serverless, system components need to be decoupled through message-driven designs. In order to benefit from no-code, people have to organize around the software production process in a different way.
Within software engineering communities no-code has been dismissed as a fad, saying the need for writing code will never go away because the needs of most software systems are too complex to capture in a visual design environment. This viewpoint ignores the argument that software engineers act as a gatekeeper, a limitation for the stakeholder to get what they want. It is reductionist to say that no-code means no-code. No-code is as much about no-code, as wireless is about the absence of wires, or serverless is about the absence of servers. No-code means less boilerplate. And no-code does NOT mean no-model.
The inability to deliver meaningful results in a reasonable amount of time is never out of bad intent, it's the consequence of rigidity in the system of work. If there is no room for experiments, for error, for trying again, then we shouldn't be surprised if people attempt moonshots. But if we can reduce the cost of experiments, then we should be able to iterate more, learn faster, and as a consequence produce more value.
Let's explore how no-code is able to remove the time to market of our ideas to explore new models. Join this session to uncover which rules, policies, and practices around modeling and design need to be replaced in order to reap the benefits that no-code has to offer.
Marijn Huizendveld works as an independent software consultant for (corporate) startups and scale-ups within Europe. He studied business school (boring though useful) and moonlighted as a freelance software engineer (limited impact, lots of fun).
After getting stung by the start-up bug he founded a SaaS business in which he was involved for the next 6 years (lots of impact, limited private life). This experience provided him with a realistic perspective on business and firm roots in software architecture. He was at the frontier of event-sourced domain models in PHP and has been actively involved in the DDD community since its revival around 2012.
These days he helps his customers to apply the lessons he picked up along the way, in order to make software that propels organizations forward. To support his clients he develops tools (such as Chameleon) that augment the software delivery process which makes teams more effective. He also laughs at his own jokes, for reasons unknown cause they typically aren’t funny. Join the workshop to see if you agree.