Slides: https://speakerdeck.com/mploed/cohesion-in-modeling-and-design

“Loose coupling & high cohesion” are key design principles for creating maintainable and understandable software. These principles can be applied on different levels of granularity ranging from classes to even systems. They also play an integral part when setting boundaries for domains and bounded contexts. While there have already been many talks and workshops on coupling at various conferences the topic of cohesion hasn’t been covered as much. This talk is all about cohesion.

We will begin by exploring the fundamental principles of cohesion in software design, illustrating its significance in creating clear, maintainable, and scalable systems. In this course you will learn what cohesion is and what kinds of cohesion there are. We will talk about types of cohesion in software design like functional, sequential, temporal or coincidental cohesion. But this talk will also look at the term cohesion in other disciplines like chemistry, geology, social behavior or soil mechanics.

In the second part this talk will cover cohesion in Domain Driven Design. A holistic approach to the topic of cohesion is especially interesting in the context of Domain Driven Design. For instance an Ubiquitous Language aims at a high degree of cohesion between terminology, conversations, code and documents within a Bounded Context. Special attention will be given to practical approaches for achieving high cohesion in domain models. We will explore real-world scenarios where cohesive design directly impacts the effectiveness of DDD, offering insights into overcoming common challenges faced in complex domain scenarios. Through this, attendees will gain a deeper appreciation of how cohesive design principles can simplify complex domain models, leading to more robust and adaptable software systems. But we will also look at the meaning of cohesion in other disciplines, which are mentioned in the intro of the talk, and learn how they can help us during collaborative and interdisciplinary design work.

This talk is designed not only for software architects and developers but also for non-technical stakeholders who wish to understand how cohesive software design can directly contribute to meeting business objectives. By the end of this session, attendees will be equipped with actionable strategies to enhance their domain models, ensuring that their software truly reflects and serves their business domain with clarity and precision.

Slides: https://speakerdeck.com/mploed/transforming-ivory-tower-architecture-to-enabling-teams

Many large organizations still work with centralized architecture-related teams. Their role is often to provide architectural specifications to other teams and ensure that these specifications are adhered to during implementation. These teams are often referred to as "ivory tower architecture" teams that aim to bundle highly skilled architects. This role is certainly not available in abundance on the market.

However, they do not fit into an agile environment where we want to give teams the opportunity to make their own decisions. Certain guard rails are nevertheless necessary to ensure that the overall construct works. In addition, well-chosen guard rails can also drastically reduce the need for coordination between teams.

We need to enable these teams to do most of the architectural work themselves, while ensuring that the individual parts fit together. This is where Team Topologies, a concept introduced by Matthew Skelton and Manuel Pais, comes into play. There is a team type called the " Enabling Team" which, in a nutshell, supports other teams with knowledge and methodology.

This presentation will give you an overview of this change as well as practical guidance on how to transform a centralized architecture team into an enabling team whose task is to improve the architecture work in other teams. You will learn:
- Which stakeholders you should involve in this process
- Why the future enabling team also needs to be empowered and how to do this
- Where common pitfalls lie on this journey
- Why this journey needs to be done in an agile way with continuous learning and retrospectives

This talk will also include many real-life examples that accompany such a transformation.

Slides: https://speakerdeck.com/mploed/failures-and-learnings-during-the-adoption-of-ddd

Domain-Driven Design is no silver bullet and does not solve any problem in magical ways. The challenges and complexity that we try to tackle with DDD are hard and there is no easy way out. Nevertheless there is a growing popularity and appreciation for the topic in the market which may lead to overly ambitious expectations and eventually to disgruntled expectations.

The speaker of this talk has been working with Domain-Driven Design for the last 17 years on many software systems and this talk is about my experiences with failure. Believe me: I have failed a lot but there is always a chance to learn. The talk aims at giving you a chance to learn from the mistakes of me as an consultant and of the teams / organizations I have been working with.

The talk will address topics like:
- Domain-Driven Design in the waterfall
- Ignorance for code (aka only focus on strategic design)
- Overusage of patterns for their own sake
- Cultural implications
- Cargo Culting
- Developer Experience
- Rare availability of domain experts
- Dealing with established modeling techniques / methods
- Ignorance for the definitions / meaning of heuristics and patterns

This talk aims at providing you with a sensibility for potential hazards when you try to adopt DDD for your team and your organization and will contain only real-worlds scenarios that have actually happened. Each described failure will also come with a learning on what to do better.

This will be an interacive talk during which you, the audience will be asked questions and polls (through an online tool). You will be able to participate.

Slides: https://speakerdeck.com/mploed/getting-modules-right-with-domain-driven-design

Domain-driven Design helps teams achieve a better alignment between the business and the technical architecture in order to design applications that have highly expressive and maintainable domain models. This talk aims at giving you an overview of Domain-driven Design and how the ideas behind it help you to create better modular applications.

We will talk about aspects from strategic Domain-driven Design such as Bounded Contexts and Subdomains, in addition to that the talk will explain the most important patterns from the tactical part of Domain-driven Design (Aggregate, Entity, Value Object). Finally you will learn about methods that help you in getting a better understanding about the domain you are working in.

Slides: https://speakerdeck.com/mploed/quality-storming

In various communities, several methods for the collaborative modeling of business requirements have been established in recent years. Well-known examples are EventStorming or Domain Storytelling. These approaches are based on achieving a better shared understanding of the business requirements in an interdisciplinary way. But what about the requirements for the quality of the software being developed?

This is where Quality Storming comes in, trying to bring together a heterogeneous set of stakeholders of a product or project to collect quality requirements. The goal is to gain a shared understanding of the real needs for the quality characteristics of a product. To achieve this goal, Quality Storming uses some techniques from various already existing collaborative modelling approaches.

It is not the claim to produce perfectly formulated quality scenarios with the help of Quality Storming. Instead, the method aims to create a well-founded, prioritized basis for later formalization, which is understood across different stakeholder groups. The more often teams work with the technique, the better the quality of this basis becomes over time. Advanced teams are quite capable of creating very well-formulated scenarios within the framework of such a workshop.

In this talks I will introduce the workshop and the ideas behind it. You will also learn many hints for facilitating such workshops and how to proceed with the learnings generated in Quality Storming workshops.

Slides: https://speakerdeck.com/mploed/systems-thinking-by-combining-team-topologies-with-context-maps

Team Topologies and Context Maps are two interesting approaches to visualize sociotechnical architectures. However, using each method on its own you will not be able to capture a truly holistic view of the system as a whole, but you can use both in combination and this is what this talk is about.

This talk will introduce a Systems Thinking perspective on those two approaches and explain how both can be leveraged in combination to get a deep dive on many interactions in a system of teams and software. Those interactions include:
- team relationships
- team dependencies
- propagation of domain models
- governance related communication
- provisioning of APIs / services

However we will also look at the components of the system with Team Topologies being team centric and Context Maps being bounded context centric.

I will finally explain how you can use both methods to visualize alignments between domains, bounded contexts and teams.

This talk assumes that you have a basic understanding of strategic Domain Driven Design (esp. Bounded Contexts and Context Maps)