9:15 Uhr, das tägliche Stand-up. Sarah, eine Entwicklerin, meldet ein Problem, das den Sprintplan gefährdet: Eine externe API blockiert eine wichtige Funktion. Nach kurzer Diskussion trifft Peter, der Product Owner, eine pragmatische Entscheidung: Ein schneller Workaround soll das Team im Zeitplan halten. Wolfgang, der Projektleiter, nickt und gibt Sarah mündlich direkt die Aufgabe, den Aufwand dafür zu schätzen.
Effizient. Pragmatisch. Entscheidung getroffen, Aufgabe verteilt.
Doch was ist mit dieser wertvollen Information passiert? Für das Daily hat das Team keine Form der Mitschrift vorgesehen. Wochen später taucht eine ähnliche Frage erneut auf. Das Team diskutiert wieder, mit dem vagen Gefühl, das Problem schon einmal gelöst zu haben. Wertvolle Zeit geht verloren, weil das Ergebnis der ursprünglichen Diskussion nirgendwo festgehalten wurde und aus dem kollektiven Gedächtnis verschwunden ist.
Diese alltägliche Situation ist ein perfektes Beispiel dafür, wo die Denkweise des Domain-Driven Designs (DDD) ansetzt. DDD ist keine fertige Lösung, sondern eine strategische Herangehensweise, die unseren Fokus lenkt, um solche Probleme tiefgreifend zu verstehen und nachhaltig zu lösen. Bevor wir über Software nachdenken, definieren wir zunächst das Spielfeld, die Domäne. Für uns grenzen wir sie klar ab: Es geht um die Welt der agilen Projektumsetzung, genauer gesagt um Teams, die in einem dynamischen Umfeld ständig Absprachen treffen müssen, um ihre Ziele zu erreichen.
Vom Problemraum zum fokussierten Lösungsraum
Bevor wir über Lösungen nachdenken, zwingt uns DDD, den Problemraum innerhalb dieser Domäne genau zu verstehen. Was sind die Probleme, bei denen wir mit einer Lösung die Mitarbeiter wirklich entlasten können? Es ist die Flut an informeller Kommunikation, die in Dailys, kurzen Calls oder Chats stattfindet. Für diese flüchtigen, aber essenziellen Informationen fehlt oft ein passender Ort. Das Resultat ist Kontextverlust und ineffiziente Doppelarbeit.
Erst wenn das Was, das Kernproblem, glasklar ist, widmen wir uns dem Wie im Lösungsraum: Wir wollen nicht das gesamte Projektmanagement neu erfinden, sondern eine Lösung exakt für das Problem der fehlenden Mitschriften bei informellen Absprachen schaffen.
Unsere Lösungsidee ist ein minimalistisches Werkzeug. Wolfgang öffnet es direkt nach dem Daily und tippt:
»Im Daily besprochen: API für #Ticket1234 liefert Null-Werte. Entscheidung von @Peter: Wir bauen einen temporären Fallback ein, um im Sprint zu bleiben. Todo: @Sarah, bitte den Aufwand schätzen.«
Der Wert dieser Lösung liegt in ihrer Einfachheit und dem Fokus auf die menschliche Erfahrung. Wolfgangs Notiz ist keine reine Abschrift, sondern eine von Erfahrung geleitete Kuratierung. Er erfasst die Essenz des Gesprächs, weil er den Kontext und die Sprache seines Teams versteht.
Die Sprache der Domäne als Fundament
Der erste Schritt zur Entwicklung unserer Lösung ist die Etablierung einer gemeinsamen Sprache, der Ubiquitous Language. Diese Sprache erfinden wir nicht, wir erleben sie im täglichen Austausch des Teams. Im Gespräch mit Wolfgang, Peter und Sarah hören wir genau hin: Eine kurze Notiz nennen alle ganz selbstverständlich einen Eintrag. Der digitale Ort, an dem ein Projekt lebt, wird zum Space.
Doch unsere Sprache geht tiefer. Wir unterscheiden präzise zwischen einem internen Mitglied und einem externen Gast, was sofort die Diskussion über Sicherheitsgrenzen klärt. Noch wichtiger sind die Verben, die unsere Kernfunktionen definieren: Nutzer bestätigen Informationen nicht, sie markieren sie als gesehen – eine bewusste, neutrale Entscheidung, die Missverständnisse über eine inhaltliche Zustimmung vermeidet. Sie filtern Themen nicht nur, sie abonnieren sie, was ihre proaktive Beziehung zu Informationen beschreibt.
Diese einfachen, aber klar definierten Begriffe aus der Lebenswelt des Teams bilden die unmissverständliche Grundlage für alles Weitere.
Die Lösung fachlich strukturieren: Von der Landkarte zum Detail
Mit dieser gemeinsamen Sprache im Gepäck geben wir unserer Lösung eine klare, fachliche Struktur. Im strategischen Design von DDD zeichnen wir die grobe Landkarte unserer Domäne. Wir fokussieren uns auf logische Verantwortungsbereiche, die Bounded Contexts. Jeder dieser Kontexte ist wie eine spezialisierte Abteilung, die sich exzellent auf eine Kernaufgabe konzentriert und klare Grenzen zu den anderen hat. So schaffen wir Ordnung und stellen sicher, dass jeder Teil der Lösung einen greifbaren Mehrwert liefert.
Anschließend zoomen wir mit dem taktischen Design in diese einzelnen Abteilungen hinein. Hier legen wir die feinen Regeln und Bausteine fest, die das Innenleben jedes Bereichs bestimmen. Konzepte wie Aggregate helfen uns dabei, Geschäftsregeln festzuschreiben und sicherzustellen, dass die Daten immer in einem logischen und konsistenten Zustand sind. So stellen wir sicher, dass die Software nicht nur technisch robust ist, sondern sich für den Nutzer auch durchweg nachvollziehbar und logisch anfühlt.
Der Schlüssel zur passenden Lösung: ein gemeinsames Verständnis
Am Ende ist Domain-Driven Design weniger eine starre Anleitung als vielmehr eine Denkweise, die das Team auf ein gemeinsames Ziel ausrichtet. Die Stärke von DDD liegt darin, den Fokus auf das Wesentliche zu lenken: ein tiefes, gemeinsames Verständnis der Fachdomäne. Aus dieser Klarheit heraus entsteht ganz natürlich ein passgenauer Lösungsraum. Für uns bedeutete das, von der vagen Idee eines »besseren Protokolls« zu einem klaren Verständnis für die flüchtigen, aber wertvollen Kommunikationsmomente in agilen Teams zu gelangen.
Dieser Ansatz lieferte nicht nur eine Blaupause für eine Software. Er schuf vor allem ein gemeinsames Verständnis und ein Fundament, das mit den zukünftigen Anforderungen an ein echtes »kollektives Gedächtnis« mitwachsen kann.
Artikel teilen
Last modified: September 17, 2025
