Hinweis: Die aktuelle OOP-Konferenz finden Sie hier!

SOFTWARE MEETS BUSINESS:
The Conference for Software Architecture
03 - 05 July 2023

menu

Conference Program

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 2023 Munich 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: DDD

Nach Tracks filtern
Alle ausklappen
  • Mittwoch
    05.07.
10:15 - 11:45
Mi 3.1
Domain Modeling Techniques for Designing Microservices
Domain Modeling Techniques for Designing Microservices

Many have suggested using DDD to help define the functional scope of microservices. But how to apply this idea in practice is not clear to everyone. This talk will cover basic DDD concepts, and we'll discuss why and how DDD can help to create microservices with better autonomy, scalability, and reliability. Using examples, we'll navigate from a domain model to the design of both synchronous (REST-based) and asynchronous (reactive) microservices.

Target Audience: Architects, Developers, PM's, QA
Prerequisites: Understanding of Microservices and DDD is useful
Level: Advanced

Extended Abstract:
Many have suggested that DDD modeling techniques can help define the functional scope of microservices. But how to apply this idea *in practice* is not clear to everyone. DDD is NOT an approach to microservice design. However, DDD can help with some aspects of microservice design. DDD has had a resurgence with the advent of Microservices, specifically as it can help you design the right-sized microservices modeled around the domain.

This talk will examine how to take the results of domain modeling (specifically Domain-Driven Design) and map them to a microservices implementation for systems with better availability, scalability, reliability, and modifiability. This will include examples for the design of both synchronous (REST-based) and asynchronous (reactive) microservices. I will also explore various microservice design scenarios around DDD concepts such as aggregates (with entities and value objects), bounded contexts, domain events, anti-corruption layer, and various strategies for Bounded Context interactions.

Joseph (Joe) Yoder is president of the Hillside Group and principal of The Refactory. He is best known as an author of the Big Ball of Mud pattern, illuminating fallacies in software architecture. Joe teaches and mentors developers on agile and lean practices, architecture, flexible systems, clean design, patterns, refactoring, and testing. Joe has presented many tutorials and talks, arranged workshops, given keynotes, and help organized leading international agile and technical conferences.

Joseph Yoder
Sydney
Joseph Yoder
Sydney
Track: DDD
Vortrag: Mi 3.1
flag VORTRAG MERKEN

Vortrag Teilen

12:00 - 12:45
Mi 3.2
Domain Storytelling – Understanding Your Users by Drawing Pictures
Domain Storytelling – Understanding Your Users by Drawing Pictures

Mehr Inhalte dieses Speakers? Kein Problem, schaut doch mal bei sigs.de vorbei: https://www.sigs.de/autor/henning.schwentner

Misunderstandings between developers and the business are a plague. Bad communication makes projects fail. This talk presents a remedy (including a practical demonstration with auditorium participation).

Domain Storytelling is a technique to transform domain knowledge into effective business software. It brings together domain experts and development teams.

We let domain experts tell us stories about their tasks. While listening, we record the stories using an easy-to-understand pictographic language.

Target Audience: Everyone involved or interested in software development, including non-technical people
Prerequisites: Curiosity
Level: Basic

Extended Abstract:
Misunderstandings between developers and the business are a plague. Bad communication makes projects fail. This talk presents a remedy (including a practical demonstration with auditorium participation).

Domain Storytelling is a technique to transform domain knowledge into effective business software. It brings together domain experts and development teams to: (a) understand the domain of a software system, (b) find microservices boundaries, and (c) talk about requirements.

We let domain experts tell us stories about their tasks. While listening, we record the stories using an easy-to-understand pictographic language.

The domain experts can see immediately whether we understand their story correctly. After very few stories, we are able to talk about the people, processes, and events in that domain.

The talk is aimed at everyone involved or interested in software development, including non-technical people.

Henning Schwentner loves programming in high quality. He lives this passion as coder, coach, and consultant at WPS – Workplace Solutions in Hamburg, Germany. There he helps teams to structure their monoliths or to build new systems from the beginning with a sustainable architecture. Microservices or self-contained systems are often the result. Henning is author of “Domain Storytelling – A Collaborative Modeling Method” and the www.LeasingNinja.io as well as translator of “Domain-Driven Design kompakt”.

Mehr Inhalte dieses Speakers? Schaut doch mal bei sigs.de vorbei: https://www.sigs.de/autor/henning.schwentner

Henning Schwentner
Ballsaal
Henning Schwentner
Ballsaal
Track: DDD
Vortrag: Mi 3.2
flag VORTRAG MERKEN

Vortrag Teilen

14:15 - 15:15
Mi 3.3
Systems thinking for impactful changes
Systems thinking for impactful changes

To understand and impact a large-scale environment (a team, an enterprise, a society), we need effective modeling. Over the years Domain-Driven Design (DDD) has gained a visible foothold in software-centric corporate change agendas.

In my work as a DDD evangelist and sociotechnical architect in large organizations, I’ve lived and breathed DDD to decouple domains and systems, to kickoff greenfield initiatives, to deploy brownfield modernization, and to design reteaming using the Inverse Conway Maneuvre and Team Topologies.

All that hard work has brought me many a pat on the shoulder. But time after time I’ve been surprised by how I/we could make things worse by attempting to make things better. I’ve been frustrated to witness bubbly energy and DDD enthusiasm from event storming workshops and alike evaporate like a deflated balloon. Improvements remained temporary and local. New practices failed to gain widespread adoption. I have to admit with absolute candor that it is so very hard to make lasting impact with DDD, or whatever else technology or tooling du jour.

In this talk, I will share my observations through the systems thinking lens, of what happened in a large change initiative in a big bank, where DDD played a central role. You will hear examples of sociotechnical systems dynamics and episodes about shifting dominance of competing feedback loops. You will be invited to partake in a postmortem forensic of what could have happened, what unfortunately didn’t happen, and the many what-if’s of alternate realities, or pasts. For people new to systems thinking, a positive side benefit can be a sneak peak into systems modeling building blocks and systems archetypes.

As a community, we’ve come a long way modeling software-centric systems, thanks to practice like DDD, architecture and Team Topologies. But what about the runtime dynamics of large human systems in our working environment, especially when such systems are full of fixes that don’t work? As software professionals, can we just tell jokes about SAFe, about policy makers in our company who can copy the Spotify Model, but not paste it? Or should we give the usual shrug – “it’s the system’s fault”?

From a systems standpoint, we are part of the same mess. If we can become better at seeing and naming the elephants in the room, not as random events, but as systemic patterns described through a consistent systems language, then the current messy reality is no longer our enemy but our ally. It can become a generative force for us to identify leverage and sustain influence in large organizational spaces.

I hope this talk will spark interest in system dynamics modeling. It is a call to action for boundary spanners and design-oriented change agents to explore abstractions, heuristics, modeling and visualization techniques to articulate and reason about dynamic system behavior.

How can we architect shared experiences to surface mental models so they can be challenged, improved and no longer stand in the way of change? With the rising initiative fatigue in large enterprises, how do we collectively discover leverage points, design and deploy systemic interventions with long lasting impacts?

Target Audience: Architects, Developers, Product Owners, Agile Coaches, Decision Makers at all levels
Prerequisites: Understanding of agile, architecture, domain-driven design
Level: Expert

Xin is a sociotechnical architect, DDD evangelist and independent consultant. She believes that a product, domain and teamoriented 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.

Xin Yao
Sydney
Xin Yao
Sydney
Track: DDD
Vortrag: Mi 3.3
flag VORTRAG MERKEN

Vortrag Teilen

15:30 - 16:30
Mi 3.4
Building Successful Software Products – an Evolutionary Approach
Building Successful Software Products – an Evolutionary Approach

Good design of software systems, much like good product design, requires immersive knowledge of the problem space. And yet we often optimize solution architecture primarily for execution, making crucial decisions about structure and technology upfront, when we still know little about the problems they are supposed to solve.
This talk will present an alternative: An incremental, evolutionary approach to building complex systems, grown holistically from the inside out, starting with the business, and optimized for fast feedback and learning.

Target Audience: Architects, Developers, Heads of IT
Prerequisites: Knowledge of design patterns and DDD basics recommended
Level: Advanced

Extended Abstract:
When we design systems from scratch, especially complex distributed systems, we tend to make far reaching decisions at a very early stage – at a time, when we have the least knowledge about the underlying business problem. But some issues are impossible to solve just by assumption, and even with great experience, it's quite common to get the first design at least partially wrong.
Unfortunately, the first design is also often the one that ends up being implemented.
On a technical level, this has immediate consequences: If we assume boundaries in the wrong place, or forget or omit important aspects of communication, we can end up with brittle services, performance issues, and needlessly coupled modules and components, which are painful to maintain and deploy.
On an organisational level, misplaced boundaries and unfortunate design decisions often lead to entire team structures and workflows in all the wrong places, thus creating immense communication overhead, or worse: active prevention of learning and improvement for the rest of the project lifetime.
One way to mitigate the impact of those decisions, and to verify our initial assumptions, is to start implementation not with a complete solution architecture in mind, but rather with the smallest possible footprint: A plain, but fully operational prototype of the domain model, which we can stress, observe, and explore – and change easily, if we run into problems. This way, we can actually _see_ our design work, and gain valuable insights.
As a side-effect, we can also deliver customer value much earlier, by using the raw domain model to power UX/UI prototypes – replacing fakes and click-dummies with a working application.
As a team, we can learn and improve together, making important decisions when they are needed, adding layer by layer of additional (technical) complexity in small, incremental steps, until we are truly ready to scale out.
By combining UX prototyping, Domain Driven Design, and making use of the fractal nature of large-scale systems, we can highlight difficult or problematic choices early, improve fundamental architecture decisions with low risk, and ultimately develop not only to better solutions, but also to a better and more sustainable software development process.

Tobias begann seine Karriere als freiberuflicher Webentwickler in den späten 90ern und hat seither an hunderten Projekten unterschiedlicher Größe und Dauer mitgewirkt – als einzelner Entwickler und mit mehreren Teams, von einigen Tagen bis zu mehreren Jahren – und in vielen unterschiedlichen Rollen: Consultant, Crafter, Coach, und ... nun ja, Architekt. Er ist ein starker Fürsprecher für Vielfalt und Inklusion in der Softwareindustrie und ein aktives Mitglied der europäischen Software-Crafting- und Domain-Driven-Design-Communitys.

Tobias Goeschel
Atlanta
Tobias Goeschel
Atlanta
Track: DDD
Vortrag: Mi 3.4
flag VORTRAG MERKEN

Vortrag Teilen

Zurück