Please note:
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.
Thema: DDD
- Montag
29.01. - Mittwoch
31.01. - Donnerstag
01.02. - Freitag
02.02.
In the times of microservices, it becomes clear how important Domain-Driven Design (DDD) still is. Only with strategic design (i.e. DDD on a large scale) and the division of the domain into bounded contexts can a sensible cut be found for the microservices.
In this workshop we will take a day to take a closer look at DDD. The workshop consists of alternating lecture, discussion and exercises.
Target Audience: Architects, Developers, Project Leaders, Managers, Decision Makers, Domain Experts
Prerequisites: None
Level: Basic
Extended Abstract:
In the times of microservices, it becomes clear how important Domain-Driven Design (DDD) still is. Only with strategic design (i.e. DDD on a large scale) and the division of the domain into bounded contexts can a sensible cut be found for the microservices.
But also Tactical Design (i.e. DDD on a small scale) with the Ubiquitous Language and the “Building Blocks” Entities, Value Objects, Aggregates, Services and co. have lost nothing of their relevance.
In this workshop we will take a day to take a closer look at DDD. The workshop consists of alternating lecture, discussion and exercises.
The structure will be such that we first give an overview of DDD and then look at the individual topics in detail. In doing so, we will approach DDD from the outside in. Content structure:
- introduction and overview
- getting to know the domain
- splitting up the domain
- learning the domain language
- model the domain
- implement the domain model
Mehr Inhalte dieses Speakers? Schaut doch mal bei sigs.de vorbei: https://www.sigs.de/autor/henning.schwentner
Henning liebt Programmieren in hoher Qualität. Diese Leidenschaft lebt er als Coder, Coach und Consultant bei der WPS – Workplace Solutions aus. Dort hilft er Teams dabei, gewachsene Monolithen zu strukturieren oder neue Systeme von Anfang an mit einer tragfähigen Architektur zu errichten. Häufig kommen dann Microservices oder Self-Contained Systems heraus. Henning ist Autor von "Domain Storytelling" (Addison-Wesley, 2022) und dem www.LeasingNinja.io sowie Übersetzer von "Domain-Driven Design kompakt" (dpunkt, 2017).
Mehr Inhalte dieses Speakers? Schaut doch mal bei sigs.de vorbei: https://www.sigs.de/experten/henning-schwentner/
Vortrag Teilen
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
Level: Advanced
Extended Abstract:
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?
DDD Consultant, Sociotechnical Architect & Advocate of Systems Thinking
Xin Yao is an independent consultant specialized in Domain-Driven Design (DDD), Sociotechnical Architecture and Systems Leadership. She frequently speaks at international design and architecture conferences. In her earlier career, Xin has been chief architect in Danske Bank, spearheading large-scale change initiatives. An experienced architect and an avid change agent, Xin nudges organizations at crossroads to move beyond seeing architecture as an upfront design blueprint. She is deeply committed to collective reasoning, participatory discovery and systems leadership. Xin facilitates languaging, modeling and reflective conversations to help teams and organisations make sense, make decisions and make intuitive business software.
Vortrag Teilen
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
Level: Basic
Extended Abstract:
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.
Mehr Inhalte dieses Speakers? Schaut doch mal bei sigs.de vorbei: https://www.sigs.de/experten/bernd-ruecker/
Vortrag Teilen
**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
Prerequisites: None
Level: Basic
Extended Abstract:
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.
Vortrag Teilen
**TL,DR**; In this course you will learn to map your business and technological landscape in such a way that a common language emerges to discuss strategic thinking and decision-making.
Max. number of participants: 13
Target Audience: Architects, Developers, Project Leaders, Decision Makers
Prerequisites: Basic theoretical knowledge of DDD
Level: Advanced
Extended Abstract:
Organizations face more and more complexity these days as a result of a mesh of products, services, technology and the people that work to build, operate and maintain them.
Domain-Driven Design helps us with solving problems the right way. But what helps us solve the right problem? How can we continuously validate our progress with people in "non-tech" roles? And what should we do when the world around us changes, which it always ends up doing? Is the plan we had still valid?
Imagine...
- Imagine having a map that helps you understand the ecosystem your organization is embedded in. A map that makes sense from both a technical and business perspective. With patterns that provide guidance about effective actions regardless of the specific domain you are working in. Wardley Mapping is that: it is a ubiquitous language around strategy and execution that helps you solve the right problem.
The course
- In this course you will learn to map your business and technological landscape in such a way that a common language emerges to discuss strategic thinking and decision making. It allows for scenario building, it teaches about bias and assumptions, and it comes packaged with a long list of ideas that may help in your situation.
The map can hint us what practices from DDD are beneficial in our situation. And it can serve as a context map too, except this one has meaning to businesspeople as well.
Using visualizations, strategies can be challenged and implementation options debated and weighed. As such, mapping is about the act and not merely the artifact. That is why this training is hands-on from the very start.
What to expect
- This class will emphasize practice over theory. Mapping with imperfect knowledge today is better than mapping with perfect knowledge next year. The course will teach you the basics and provides hooks into the theoretical aspects behind exercises.
Who should attend
- Anyone that wants to challenge the status quo of decision making under uncertainty in technology and business. No prior knowledge is required and your open attitude to learn new things will be an asset during the workshop.
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.
Vortrag Teilen