Schwerpunktthema

Domain-driven Design

Domain-driven Design richtet die Struktur von Software an den fachlichen Grenzen eines Unternehmens aus, mit Bounded Contexts und einer gemeinsamen Sprache zwischen Fachbereich und Entwicklung.

Domain-driven Design: Von der Fachlichkeit zur Softwarearchitektur

Domain-driven Design (DDD) beschreibt einen Ansatz, um komplexe Softwaresysteme entlang fachlicher Grenzen zu strukturieren. Zentrale Konzepte sind Bounded Contexts als klar abgegrenzte Modellbereiche, eine Ubiquitous Language als gemeinsames Vokabular zwischen Fachbereich und Entwicklung sowie die Unterscheidung zwischen strategischem und taktischem Design.

In der Praxis wird DDD häufig eingesetzt, um große Systeme entlang fachlicher Grenzen zu strukturieren. Bounded Contexts können dabei die Grundlage für unabhängig entwickelbare Bausteine wie Microservices bilden, statt das System primär entlang technischer Schichten zu schneiden. Diesen Ansatz vertieft die Schulung Domain-driven Design in der Praxis.

Diese Seite bündelt Fachartikel, Podcasts, Vorträge und Primer rund um Domain-driven Design.

Unsere Leistungen

Wir beraten ehrlich, denken innovativ und entwickeln leidenschaftlich gern. Das Ergebnis sind erfolgreiche Softwarelösungen, Infrastrukturen und Geschäftsmodelle.

Blog-Posts

Podcast

Aktuelles

Vorträge

Primer

Häufige Fragen

Sie haben Fragen zum Thema Domain-driven Design? Hier finden Sie Antworten auf Fragen, die wir häufig gestellt bekommen.

Wann ist Domain-driven Design sinnvoll?

Domain-driven Design eignet sich besonders für Systeme mit komplexer Fachlogik, vielen beteiligten Teams oder Domänen, in denen Begriffe und Regeln nicht eindeutig sind. DDD hilft dabei, fachliche Zusammenhänge gemeinsam mit Domänenexpert:innen zu verstehen und diese Erkenntnisse in die Struktur der Software zu übersetzen. Für einfache CRUD-Anwendungen oder Systeme mit wenig Fachlogik ist der zusätzliche Modellierungsaufwand dagegen oft nicht notwendig. INNOQ setzt DDD in Architektur- und Entwicklungsprojekten ein, wenn fachliche Komplexität die Struktur eines Systems maßgeblich bestimmt: Softwarearchitektur und -entwicklung

Was ist ein Bounded Context und wie finde ich die richtigen Grenzen?

Ein Bounded Context definiert einen Bereich, innerhalb dessen ein fachliches Modell und seine Begriffe eindeutig gelten. Gute Grenzen entstehen nicht allein aus technischen Kriterien wie Datenbanken oder Services, sondern aus fachlichen Verantwortlichkeiten, Geschäftsprozessen und unterschiedlichen Bedeutungen von Begriffen. Methoden wie Event Storming oder Domain Storytelling helfen dabei, diese Grenzen gemeinsam sichtbar zu machen und zu überprüfen.

In der iSAQB®-Schulung Domain-driven Design in der Praxis lernst du verschiedene Ansätze kennen, um Subdomänen und Bounded Contexts systematisch zu identifizieren.

Wie hängen Domain-driven Design und Microservices zusammen?

DDD und Microservices sind zwei unterschiedliche Konzepte. DDD hilft dabei, fachlich sinnvolle Grenzen und Modelle zu finden. Microservices sind eine mögliche technische Form, diese Grenzen umzusetzen. Ein Bounded Context muss deshalb nicht automatisch einem einzelnen Microservice entsprechen.

Gerade vor einer Aufteilung in Microservices kann strategisches DDD helfen, fachliche Abhängigkeiten zu verstehen und zu vermeiden, dass lediglich ein verteilter Monolith entsteht.

Wie hilft Domain-driven Design bei Legacy-Systemen?

Bei Legacy-Systemen kann DDD helfen, fachliche Strukturen sichtbar zu machen, die im bestehenden Code nicht mehr eindeutig erkennbar sind. Statt das gesamte System auf einmal neu zu bauen, lassen sich Domänen, Abhängigkeiten und geeignete Schnittstellen identifizieren und schrittweise neu strukturieren.

Bounded Contexts können dabei als Zielbild dienen, um Teile eines Systems gezielt zu entkoppeln und Modernisierungsschritte entlang fachlicher Grenzen zu planen.

Für diesen Anwendungsfall bietet socreatory unter anderem den Workshop Domain-driven Design saniert Legacy an.

Wie unterstützt INNOQ Teams bei Domain-driven Design?

INNOQ unterstützt Teams dabei, komplexe Domänen zu verstehen, fachlich sinnvolle Systemgrenzen zu entwickeln und diese in Softwarearchitektur und Teamstrukturen zu übersetzen. Je nach Ausgangslage reicht das von kollaborativer Modellierung und Architekturarbeit bis zur Begleitung bestehender Entwicklungsprojekte.

Für den Wissenstransfer bieten wir außerdem die iSAQB®-Schulung Domain-driven Design in der Praxis an. Für strategische und organisatorische Fragestellungen kann DDD außerdem Teil unserer Architekturstrategie sein.