Warum Ihr Code ein Chaos ist: Fünf Gründe für unklare Kundenmodelle

Ein neuer Entwickler steigt in Ihr Team ein, öffnet den Code und starrt auf eine Klasse namens Kunde. Doch was bedeutet das überhaupt? Für die Buchhaltung ist es eine Rechnungsadresse, für das Marketing ein Lead, für die Logistik ein Versandpartner. Plötzlich wird aus einem einfachen Begriff ein Gewirr aus Sonderfällen, Workarounds und versteckten Abhängigkeiten.

Dieses Problem ist kein Einzelfall. Viele Codebasen wachsen zu unwartbaren Monolithen heran, weil Teams keine klare Vorstellung davon haben, was sie eigentlich modellieren. Die Technologie ist dabei oft nicht das Hindernis – sondern die Art und Weise, wie das Unternehmen selbst seine Prozesse definiert. Domain-Driven Design (DDD) bietet einen strukturierten Ansatz, um diese Lücke zwischen Business und Code zu schließen. Hier erfahren Sie, wie Sie damit beginnen – ohne akademischen Ballast.

Warum ein einziges „Kunde“-Modell scheitert

Stellen Sie sich vor, Sie würden eine Landkarte erstellen, die gleichzeitig U-Bahn-Linien, Unterwasserströmungen, Wanderwege und Flugrouten abbildet. Sie wäre unbrauchbar. Jede dieser Darstellungen hat ihren eigenen Zweck und ihre eigene Logik. Doch genau das passiert in vielen Softwareprojekten: Ein einziges Modell soll alle Anforderungen erfüllen – von der Rechnungsstellung bis zur Kundenkommunikation.

Das Ergebnis? Eine überladene Klasse mit Dutzenden von Attributen, die niemand mehr vollständig versteht. Jede Abteilung fügt ihre eigenen Felder hinzu, aber niemand entfernt veraltete oder widersprüchliche Eigenschaften. Mit der Zeit wird aus dem Modell ein undurchdringlicher Dschungel, in dem sich nur noch diejenigen zurechtfinden, die jahrelang daran gearbeitet haben.

Dieses Phänomen nennt man das monolithische Modell-Fallen. Es entsteht, wenn Teams versuchen, ein universelles Modell für alle Use Cases zu schaffen – statt für den spezifischen Kontext, in dem es tatsächlich benötigt wird.

Strategisches Design: Business und Code in Einklang bringen

DDD unterteilt die Designarbeit in zwei Phasen: strategisches Design und taktisches Design. Ersteres kommt vor dem ersten Codezeile – und entscheidet darüber, ob Ihr Projekt langfristig wartbar bleibt.

Schritt 1: Subdomänen identifizieren

Eine Subdomäne ist ein klar abgegrenzter Ausschnitt des Geschäftsmodells. Beispiele sind:

• Bestellmanagement
• Versandlogistik
• Benachrichtigungssysteme
• Zahlungsabwicklung
• Lagerverwaltung

Wichtig: Diese Subdomänen entstehen nicht in einem Meetingraum voller Entwickler. Sie müssen gemeinsam mit den Fachabteilungen erarbeitet werden. Nur so stellen Sie sicher, dass Ihre Software nicht nur technisch funktioniert, sondern auch fachlich korrekt ist.

Sobald Sie die Subdomänen kennen, klassifizieren Sie sie nach ihrer Bedeutung:

• Kern-Subdomänen: Ihr Wettbewerbsvorteil. Hier sollten Ihre besten Entwickler arbeiten.
• Unterstützende Subdomänen: Notwendig, aber nicht einzigartig. Können einfach umgesetzt oder ausgelagert werden.
• Generische Subdomänen: Standardprobleme wie E-Mail-Versand. Hier lohnt sich der Einsatz fertiger Lösungen.

Schritt 2: Eine einheitliche Sprache etablieren

Der vielleicht wichtigste – und gleichzeitig einfachste – Schritt in DDD ist die Einführung einer ubiquitären Sprache. Das bedeutet: Business und Entwickler verwenden exakt dieselben Begriffe für dieselben Konzepte. Keine Synonyme, keine Übersetzungen, keine Abkürzungen.

Wenn die Fachabteilung von einer „Abonnement“ spricht, muss der Code diese Bezeichnung verwenden – nicht „Plan“ oder „Vertrag“. Wenn der Kundensupport von einem „Ticket“ spricht, darf der Code nicht von einem „Fall“ reden. Jede Abweichung führt zu Missverständnissen, die sich in Bugs, doppelten Implementierungen und endlosen Diskussionen niederschlagen.

Schritt 3: Event Storming durchführen

Bevor Sie Architekturentscheidungen treffen, sollten Sie ein Event Storming veranstalten. Laden Sie Fachleute und Entwickler in einen Raum und sammeln Sie alle Ereignisse, die in Ihrem System stattfinden – formuliert in der Vergangenheit:

• „Bestellung aufgegeben“
• „Zahlung bestätigt“
• „Drohne gestartet“
• „Kunde benachrichtigt“

Anschließend identifizieren Sie die Befehle, die diese Ereignisse auslösen, und die Akteure, die sie ausführen. Die Ergebnisse kleben Sie an eine Wand und clustern sie nach Mustern. So erkennen Sie nicht nur Ihre Subdomänen, sondern auch deren Wechselwirkungen – bevor Sie auch nur eine Zeile Code geschrieben haben.

Bounded Contexts: Wo die Sprache ihre Grenzen findet

Ein zentrales Konzept in DDD sind bounded Contexts – abgegrenzte Bereiche, in denen ein Begriff eine eindeutige Bedeutung hat. Das klingt zunächst widersprüchlich: Sollte ein Begriff nicht überall dasselbe bedeuten? Die Antwort lautet: Nein, und das ist auch in Ordnung.

Ein klassisches Beispiel ist die Bedeutung des Wortes „Tomate“:

• In der Botanik ist sie eine Frucht.
• In der Küche ist sie ein Gemüse.

Beide Definitionen sind korrekt – aber in unterschiedlichen Kontexten.

Ähnlich verhält es sich in Ihrer Software:

• In der Abrechnung ist ein „Abonnent“ ein Kunde mit einem aktiven Vertrag, einer Zahlungsmethode und einem Abrechnungszyklus.
• Im Benachrichtigungssystem ist ein „Abonnent“ ein Endpunkt, der Nachrichten empfängt.

Wenn Sie versuchen, diese beiden Bedeutungen in einer einzigen Klasse abzubilden, entsteht ein Modell, das weder für die Abrechnung noch für die Benachrichtigungen funktioniert. Bounded Contexts ziehen klare Grenzen und definieren innerhalb dieser Grenzen eine konsistente Sprache. Außerhalb dieser Grenzen müssen Übersetzungen bewusst und strukturiert erfolgen.

Kontextkarten: Die unsichtbaren Verbindungen zwischen Teams

Bounded Contexts existieren nicht isoliert. Ein Bestellkontext muss mit einem Versandkontext kommunizieren, ein Zahlungskontext mit einem Benachrichtigungskontext. Eine Kontextkarte dokumentiert diese Wechselwirkungen und legt fest, wie die Kommunikation abläuft:

• Partnerschaft: Zwei Kontexte arbeiten eng zusammen und teilen sich möglicherweise sogar Code.
• Kunde-Lieferant: Ein Kontext stellt eine API bereit, die ein anderer nutzt.
• Konformist: Ein Kontext akzeptiert die Sprache eines anderen, ohne sie zu hinterfragen.
• Separate Wege: Zwei Kontexte haben keine direkte Verbindung und agieren unabhängig voneinander.

Besonders wichtig ist die Eigentümerschaft eines Contexts. Wenn zwei Teams denselben Codebereich verantworten, entsteht automatisch Kopplung – nicht nur im Code, sondern auch in den Entscheidungsprozessen. Ein klar definierter Eigentümer pro Context reduziert diese Reibung und macht Ihren Codebase langfristig wartbar.

Fazit: Von der Theorie zur Praxis

Domain-Driven Design ist kein Allheilmittel, aber es bietet einen strukturierten Weg, um die Kluft zwischen Business und Code zu überbrücken. Der Schlüssel liegt nicht in der Umsetzung aller Konzepte auf einmal, sondern darin, mit den Grundlagen zu beginnen:

1. Klären Sie Ihre Begriffe mit den Fachabteilungen.
2. Definieren Sie Subdomänen und deren Bedeutung.
3. Ziehen Sie klare Grenzen zwischen den Kontexten.
4. Dokumentieren Sie die Wechselwirkungen zwischen den Kontexten.

Selbst wenn Sie nur die ubiquitäre Sprache einführen und Event Storming durchführen, werden Sie bereits eine spürbare Verbesserung in Ihrer Codequalität und Teamkommunikation feststellen. Der Rest folgt mit der Zeit – Schritt für Schritt, ohne akademischen Overhead.

Die Alternative? Weitermachen wie bisher: mit einem Code, der niemandem mehr etwas sagt, außer den wenigen, die ihn seit Jahren pflegen.