INNOQ - Fellow
Michael works as a Fellow for INNOQ in Germany. He has over 15 years of practical consulting experience in software development and architecture. His main areas of interest are currently Domain-driven Design, Microservices and in general Software Architectures. Michael is a regular speaker at national and international conferences.
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.
Often, the architectural documentation of a project / product is designed in the privacy of the architect's office. However, in the environment of collaborative modeling approaches, which are very popular in the Domain-driven Design community, there are numerous approaches and methods how to develop parts of the architectural design and thus also the documentation together with stakeholders. This is the starting point of the presentation, which is based on the arc42 template and covers the following topics:
- How to achieve a good technical context delimitation with EventStorming.
- How to identify first building block candidates in EventStorming with the help of pivotal events, swimlanes and temporal boundaries
- How to describe building blocks in the building block view using the Bounded Context Canvas
- How to use Quality Storming for the identification of quality scenarios
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.
Over the last couple of months and years I have always been confronted with the question „how to I sell or pitch the ideas behind Domain-driven Design to our management“?
This session aims to give you some advices how to address this challenge. Many of these advices are practically tested in various presentations and pitches to various senior and C-Level managers. Some of those were successful, others not so much and I will share some stories from the trenches of both outcomes.
I‘ll give you hints how to structure an argument for DDD, which parts of our beloved practice are of interest for those stakeholders and why you should also look beyond the IT-management for your pitch.
This talks is all about riding to the penthouse of Gregor Hohpe's elevator with DDD in your backpack.
Context Maps, are a part of strategic Domain-driven Design whichs aims at delivering a holistic overview over the interactions between bounded contexts and teams. They make the implicitly hidden organizational dynamics explicitly visible.
This talk introduces you to the motivation and the benefit for Context Maps. You will also learn about the three team dependencies and nine patterns which make up a Context Map. The talk also aims at delivering a consistent visual presentation for context maps and will give you an overview of tools and free resources which are available.
This talks is explicitly aimed at newbies to the topic and is no deep dive for seasoned experts.
In his book "The Software Architect Elevator" Gregor Hohpe uses the analogy of an elevator in a high building for the daily work which software architects should be doing: They are supposed to talk to folks who build and maintain stuff in the engine room but also make sure that the managment which is residing on the penthouse floors understand and gain interest in what is happening in the engine room.
In my talk I will build upon Gregors ideas and show you how you can leverage ideas from Domain Driven Design in this daunting communication tasks. But rest assured: I will not only present the obvious strategic Domain Drivend Design elements like core / supporting / generic subdomains here. We will go deeper and explore links to other initiatives in an org like DevOps, Agile and / org Design Thinking as well which are of interest for the leadership of an organization.
We as a community should get better at this topic because Domain Driven Design needs a healthy, blame free and safe environment in order to flourish and this environment needs to be established and lived by the leadership folks.
PS: The talk idea and usage of Gregors elevator analogy have been approved by Gregor
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)
Of course we all love our favorite technologies and of couse it is important to understand your tech stack as a developer. Certainly you become a great developer or architect by understanding modern patterns and architectures.
But isn’t it a bit boring to just churn out code just for codes sake?
In this talk I want to motivate you to leave your comfort zone and to take a step back. This talk aims at motivating you as a developer or an architect to dig deep into the domain of your business and your product. I firmly believe that this will make you a great and especially a more valuable developer. If we understand the business we can make better design choices as developers / architects. We can highlight misalignments in our organization. We will be able to come up with better tests.
This talk will not just be limited to the motivating side of this topic. I will also give you tons of hints and tips how you can get started in this journey, who your allies may be and how to tackle this difficult task. This talk will also come with many examples of success and failure from the real world. I guess we will laugh a lot during this session but sometimes we’ll also shake our heads in utter disbelieve in those 50 minutes.
INNOQ - Fellow