Einführung in Domain-Driven Design E-Book

Vlad Khononov

• Herausgeber: O'Reilly
• Kategorie: Wissenschaft und neue Technologien
• Serie: Animals
• Sprache: Deutsch
• Veröffentlichungsjahr: 2022

Seitenzahl: 410

Beschreibung

Hands-On DDD: von der Strategie bis zum technischen Design

• Anspruchsvolles Thema, von einem DDD-Praktiker gut lesbar aufgeschlüsselt
• Fokus auf der strukturierten DDD-Denkweise und den zentralen Prinzipien
• Konkrete Hilfestellungen, wann Patterns genutzt werden sollten und wann nicht
• Kompakte Codebeispiele - gerade vollständig genug, um Grundideen zu vermitteln

Softwareentwicklung ist heutzutage anspruchsvoller denn je: Als Entwicklerin oder Entwickler müssen Sie technologische Trends im Blick behalten, aber genauso die Business Domains hinter der Software verstehen.
Dieser Praxisratgeber beschreibt zentrale Patterns, Prinzipien und Praktiken, mit denen Sie Geschäftsbereiche analysieren, die Business-Strategie verstehen und, was am wichtigsten ist, Ihr Softwaredesign besser an den Geschäftsanforderungen ausrichten können.
DDD-Praktiker Vlad Khononov zeigt Ihnen, wie diese Praktiken zu einer robusten Implementierung der Geschäftslogik führen und Ihr Softwaredesign und Ihre Softwarearchitektur zukunftsfähig machen. Abschließend wird DDD in Verbindung mit Microservices-basierten, Event-getriebenen und Data-Mesh-Architekturen beleuchtet.

Leseprobe

Über dieses Buch

Vladik Khononov ist ein scharfsinniger Denker, der seit Jahren DDD anwendet, um reale Business-Probleme zu lösen. Seine Ideen bringen die gesamte DDD-Community immer wieder voran, und dieses Buch wird DDD-Einsteiger inspirieren.

– Nick Tune, Technology Consultant

Was mir beim Lesen der Entwürfe dieses Buchs durch den Kopf ging und was mir besonders Spaß daran gemacht hat, ist, dass es das Versprechen seines Titels erfüllt! Es ist ein einladender und informativer Praxisratgeber, der das gesamte Feld des DDD abdeckt – von der Strategie bis hin zum technischen Design. Ich habe ein tieferes Verständnis von DDD und neue Einblicke in Bereiche erhalten, in denen ich schon Erfahrung besaß, und Konzepte und Praktiken kennengelernt, mit denen ich bisher weniger zu tun hatte. Vlad ist ein wundervoller Lehrer!

– Ruth Malan, Architecture Consultant bei Bredemeyer Consulting

Vlad hat bei seiner Arbeit an ausgesprochen komplexen Projekten Erfahrungen als DDD-Praktiker gesammelt und teilt dieses Wissen immer sehr gerne. In diesem Buch erzählt er die Geschichte des DDD auf eine einmalige Art und Weise und ermöglicht uns damit, sehr viel darüber zu lernen. Dieses Buch ist für Neueinsteigerinnen und Neueinsteiger gedacht, aber auch ich, die DDD schon lange praktiziert und über DDD schreibt und spricht, habe festgestellt, dass ich durch seine Sichtweise sehr viel gelernt habe.

– Julie Lerman, Software-Coach, O’Reilly-Autorin und engagierte DDD-Advokatin

Copyright und Urheberrechte:

Die durch die dpunkt.verlag GmbH vertriebenen digitalen Inhalte sind urheberrechtlich geschützt. Der Nutzer verpflichtet sich, die Urheberrechte anzuerkennen und einzuhalten. Es werden keine Urheber-, Nutzungs- und sonstigen Schutzrechte an den Inhalten auf den Nutzer übertragen. Der Nutzer ist nur berechtigt, den abgerufenen Inhalt zu eigenen Zwecken zu nutzen. Er ist nicht berechtigt, den Inhalt im Internet, in Intranets, in Extranets oder sonst wie Dritten zur Verwertung zur Verfügung zu stellen. Eine öffentliche Wiedergabe oder sonstige Weiterveröffentlichung und eine gewerbliche Vervielfältigung der Inhalte wird ausdrücklich ausgeschlossen. Der Nutzer darf Urheberrechtsvermerke, Markenzeichen und andere Rechtsvorbehalte im abgerufenen Inhalt nicht entfernen.

Einführung inDomain-Driven Design

Von der Business-Strategie zumtechnischen Design

Vlad Khononov

Deutsche Übersetzung vonThomas Demmig

Vlad Khononov

Lektorat: Ariane Hesse

Fachliche Unterstützung: Jörn Koch, Henning Schwentner

Übersetzung: Thomas Demmig

Korrektorat: Sibylle Feldmann, www.richtiger-text.de

Satz: III-Satz, www.drei-satz.de

Herstellung: Stefanie Weidner

Umschlaggestaltung: Karen Montgomery, Michael Oréal, www.oreal.de

Bibliografische Information der Deutschen Nationalbibliothek

Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über http://dnb.d-nb.de abrufbar.

ISBN:

Print

978-3-96009-195-0

PDF

978-3-96010-732-3

ePub

978-3-96010-733-0

mobi

978-3-96010-734-7

1. Auflage 2022

Translation Copyright für die deutschsprachige Ausgabe © 2022 dpunkt.verlag GmbH

Wieblinger Weg 17

69123 Heidelberg

Authorized German translation of the English edition of Learning Domain-Driven Design

ISBN 9781098100131 © 2022 Vladislav Khononov. This translation is published and sold by permission of O’Reilly Media, Inc., which owns or controls all rights to publish and sell the same.

Dieses Buch erscheint in Kooperation mit O’Reilly Media, Inc. unter dem Imprint »O’REILLY«. O’REILLY ist ein Markenzeichen und eine eingetragene Marke von O’Reilly Media, Inc. und wird mit Einwilligung des Eigentümers verwendet.

Hinweis:

Dieses Buch wurde auf PEFC-zertifiziertem Papier aus nachhaltiger Waldwirtschaft gedruckt. Der Umwelt zuliebe verzichten wir zusätzlich auf die Einschweißfolie.

Schreiben Sie uns:

Falls Sie Anregungen, Wünsche und Kommentare haben, lassen Sie es uns wissen: [email protected].

Die vorliegende Publikation ist urheberrechtlich geschützt. Alle Rechte vorbehalten. Die Verwendung der Texte und Abbildungen, auch auszugsweise, ist ohne die schriftliche Zustimmung des Verlags urheberrechtswidrig und daher strafbar. Dies gilt insbesondere für die Vervielfältigung, Übersetzung oder die Verwendung in elektronischen Systemen.

Es wird darauf hingewiesen, dass die im Buch verwendeten Soft- und Hardware-Bezeichnungen sowie Markennamen und Produktbezeichnungen der jeweiligen Firmen im Allgemeinen warenzeichen-, marken- oder patentrechtlichem Schutz unterliegen.

Alle Angaben und Programme in diesem Buch wurden mit größter Sorgfalt kontrolliert. Weder Autor noch Verlag noch Übersetzer können jedoch für Schäden haftbar gemacht werden, die in Zusammenhang mit der Verwendung dieses Buches stehen.

5 4 3 2 1 0

Inhalt

Grußwort

Vorwort

Einleitung

Teil IStrategisches Design

1Fachdomänen analysieren

Was ist eine Fachdomäne?

Was ist eine Subdomain?

Arten von Subdomains

Subdomains vergleichen

Grenzen von Subdomains ermitteln

Beispiele für eine Analyse der Fachdomäne

Gigmaster

BusVNext

Wer sind die Domänenexperten?

Zusammenfassung

Übungen

2Domänenwissen ermitteln

Fachliche Probleme

Erlernen von Fachwissen

Kommunikation

Was ist eine Ubiquitous Language?

Sprache der Domänenexperten

Szenarien

Konsistenz

Modell der Fachdomäne

Was ist ein Modell?

Effektives Modellieren

Die Fachdomäne modellieren

Kontinuierliche Arbeit

Werkzeuge

Herausforderungen

Zusammenfassung

Übungen

3Die Komplexität einer Domain im Griff behalten

Inkonsistente Modelle

Was ist ein Bounded Context?

Modellgrenzen

Verbesserte Ubiquitous Language

Gültigkeitsbereich eines Bounded Context

Bounded Contexts versus Subdomains

Subdomains

Bounded Contexts

Die Verbindung zwischen Subdomains und Bounded Contexts

Grenzen

Physische Grenzen

Zuständigkeitsgrenzen

Bounded Contexts in der Realität

Semantic Domains

Wissenschaft

Einen Kühlschrank kaufen

Zusammenfassung

Übungen

4Bounded Contexts integrieren

Kooperation

Partnership

Shared Kernel

Customer/Supplier

Conformist

Anticorruption Layer

Open-Host Service

Separate Ways

Kommunikationsprobleme

Generic Subdomains

Modellunterschiede

Context Map

Wartung

Einschränkungen

Zusammenfassung

Übungen

Teil IITaktisches Design

5Einfache Business-Logik implementieren

Transaction Script

Implementierung

So einfach ist es nicht!

Wann man ein Transaction Script verwendet

Active Record

Implementierung

Wann sollte Active Record genutzt werden?

Seien Sie pragmatisch

Zusammenfassung

Übungen

6Komplexe Business-Logik angehen

Geschichte

Domain Model

Implementierung

Bausteine

Komplexität managen

Zusammenfassung

Übungen

7Die zeitliche Dimension modellieren

Event Sourcing

Suche

Analyse

Source of Truth

Event Store

Event-Sourced Domain Model

Vorteile

Nachteile

Häufige Fragen

Performance

Daten löschen

Warum kann ich nicht einfach …?

Zusammenfassung

Übungen

8Architektur-Patterns

Business-Logik versus Architektur-Patterns

Schichtenarchitektur

Presentation Layer

Business Logic Layer

Data Access Layer

Kommunikation zwischen den Schichten

Variation

Wann Schichtenarchitektur genutzt werden sollte

Ports & Adapters

Terminologie

Dependency Inversion Principle

Integration von Infrastrukturkomponenten

Varianten

Wann man Ports & Adapters verwendet

Command-Query Responsibility Segregation

Polyglot Modeling

Implementierung

Read Models projizieren

Herausforderungen

Model Segregation

Wann CQRS verwendet wird

Scope

Zusammenfassung

Übungen

9Kommunikations-Patterns

Model Translation

Stateless Model Translation

Stateful Model Translation

Aggregates integrieren

Outbox

Saga

Process Manager

Zusammenfassung

Übungen

Teil IIIDomain-Driven Design in der Praxis umsetzen

10Designheuristiken

Heuristik

Bounded Contexts

Implementierungs-Patterns für Business-Logik

Architektur-Patterns

Teststrategie

Testpyramide

Testdiamant

Umgekehrte Testpyramide

Entscheidungsbaum für taktisches Design

Zusammenfassung

Übungen

11Evolution von Designentscheidungen

Änderungen an Domains

Core nach Generic

Generic nach Core

Supporting nach Generic

Supporting nach Core

Core nach Supporting

Generic nach Supporting

Strategische Designaspekte

Taktische Designaspekte

Transaction Script nach Active Record

Active Record nach Domain Model

Domain Model nach Event-Sourced Domain Model

Alte Übergänge generieren

Migrationsevents modellieren

Organisationsänderungen

Partnership nach Customer/Supplier

Customer/Supplier nach Separate Ways

Domänenwissen

Wachstum

Subdomains

Bounded Contexts

Aggregates

Zusammenfassung

Übungen

12EventStorming

Was ist EventStorming?

Wer sollte am EventStorming teilnehmen?

Was brauchen Sie zum EventStorming?

Der EventStorming-Prozess

Schritt 1: Unstrukturiertes Erforschen

Schritt 2: Zeitachsen

Schritt 3: Pain Points

Schritt 4: Pivotal Events

Schritt 5: Commands

Schritt 6: Policies

Schritt 7: Read Models

Schritt 8: Externe Systeme

Schritt 9: Aggregates

Schritt 10: Bounded Contexts

Varianten

Wann Sie EventStorming einsetzen

Tipps für das EventStorming

Achten Sie auf die Dynamik

Remote EventStorming

Zusammenfassung

Übungen

13Domain-Driven Design in der Praxis

Strategische Analyse

Die Fachdomäne verstehen

Das aktuelle Design untersuchen

Modernisierungsstrategie

Strategisches Modernisieren

Taktisches Modernisieren

Eine Ubiquitous Language kultivieren

Pragmatisches Domain-Driven Design

Domain-Driven Design schmackhaft machen

Undercover Domain-Driven Design

Zusammenfassung

Übungen

Teil IVDDD und andere Methodiken und Patterns

14Microservices

Was ist ein Service?

Was ist ein Microservice?

Method as a Service: Perfekte Microservices?

Designziel

Systemkomplexität

Microservices als tiefe Services

Microservices als tiefe Module

Domain-Driven Design und die Grenzen von Microservices

Bounded Contexts

Aggregates

Subdomains

Die öffentlichen Schnittstellen von Microservices komprimieren

Open-Host Service

Anticorruption Layer

Zusammenfassung

Übungen

15Event-Driven Architecture

Event-Driven Architecture

Events

Events, Commands und Messages

Struktur

Event-Typen

Design einer Event-gesteuerte Integration

Verteilter Big Ball of Mud

Zeitliche Kopplung

Funktionelle Kopplung

Implementierungskopplung

Die Event-gesteuerte Integration refaktorieren

Event-gesteuerte Designheuristiken

Zusammenfassung

Übungen

16Data Mesh

Analytisches Datenmodell versus transaktionales Datenmodell

Fact-Tabelle

Dimension-Tabelle

Analytische Modelle

Plattformen zum Managen analytischer Daten

Data Warehouse

Data Lake

Herausforderungen von Data Warehouse und Data Lake Architectures

Data Mesh

Daten anhand von Domains unterteilen

Daten als Produkt

Autonomie ermöglichen

Ein Ökosystem schaffen

Data Mesh und Domain-Driven Design kombinieren

Zusammenfassung

Übungen

Abschließende Worte

Anhang ADDD anwenden: eine Fallstudie

Anhang BAntworten auf die Übungsfragen

Literatur

Index

Grußwort

Domain-Driven Design stellt eine Reihe von Praktiken bereit, um gemeinsam Software aus der Sicht des Business zu bauen – genau die Domäne und die Probleme, die Sie angehen wollen. Der Begriff wurde ursprünglich von Eric Evans im Jahr 2003 mit der Veröffentlichung des Buchs Domain-Driven Design: Tackling Complexity in the Heart of Software geprägt, das in der DDD-Community als »Blue Book« bezeichnet wird.

Zwar besteht das Ziel von Domain-Driven Design darin, die Komplexität zu reduzieren und einen klaren Pfad aufzuzeigen, aber es gibt dabei auch viele tolle Ideen, die ebenso auf weniger komplizierte Projekte angewendet werden können. DDD erinnert uns daran, dass Entwickler und Entwicklerinnen nicht die einzigen am Bau von Software beteiligten Personen sind. Die Domänenexperten oder Fachexperten (engl. Domain Experts), für die die Software gebaut wird, bringen ein entscheidendes Verständnis für die zu lösenden Probleme mit. Wir schaffen während der verschiedenen Stadien eine Partnerschaft, indem wir zunächst »strategisches Design« anwenden, um das Business-Problem – also die Domäne – zu verstehen. Dann teilen wir das Problem in kleinere, lösbare und miteinander verbundene Probleme auf. Die Partnerschaft mit den Domänenexperten hilft uns auch dabei, in der Sprache der Domäne zu kommunizieren, statt die Business-Seite dazu zu zwingen, die technische Sprache der Software erlernen zu müssen.

Das zweite Stadium eines DDD-basierten Projekts ist das »taktische Design«, bei dem wir die Erkenntnisse des strategischen Designs in Softwarearchitektur und -Implementierung umsetzen. Auch hier liefert das DDD wieder Ratschläge und Patterns für das Organisieren dieser Domänen und das Vermeiden zusätzlicher Komplexität. Im taktischen Design geht die Partnerschaft weiter, wenn die Domänenexperten beim Blick auf den von den Softwareteams gebauten Code ihre Domänensprache wiedererkennen.

Seit der Veröffentlichung des »Blue Book« haben nicht nur viele Organisationen von den Ideen profitiert, es hat sich auch eine Gemeinschaft aus erfahrenen DDD-Praktikern gebildet. Und die kollaborative Natur von DDD sorgt dafür, dass diese Gemeinschaft ihre Erfahrungen und Perspektiven gerne weitergibt und Tools hervorbringt, die Teams dabei helfen, diese Ideen anzunehmen und Nutzen aus ihnen zu ziehen. In einer Keynote zur Explore DDD 2019 ermutigte Eric Evans die Gemeinschaft darin, DDD weiterhin voranzubringen – und nicht nur deren Praktiken zu entwickeln, sondern auch Wege zu finden, die Ideen von DDD effektiver zu verbreiten.

Und das bringt mich dazu, warum ich ein so großer Fan von Einführung in Domain-Driven Design bin. Ich war von Vlad schon aufgrund seiner Vorträge auf Konferenzen und seiner anderen Texte begeistert. Er hat bei seiner Arbeit an ausgesprochen komplexen Projekten Erfahrungen als DDD-Praktiker gesammelt und teilt dieses Wissen immer sehr gerne. In diesem Buch erzählt er die Geschichte des DDD (nicht die Historie, sondern die Konzepte) auf eine einmalige Art und Weise, und er ermöglicht uns damit, sehr viel darüber zu lernen. Dieses Buch ist für Neueinsteigerinnen und Neueinsteiger gedacht, aber auch ich, die DDD schon lange praktiziert und über DDD schreibt und spricht, habe festgestellt, dass ich durch seine Sichtweise sehr viel gelernt habe. Ich habe auf das Buch in meinem DDD-Fundamentals-Kurs bei Pluralsight schon hingewiesen, bevor es überhaupt veröffentlicht wurde, und habe einige seiner Sichtweisen in Gesprächen mit Kunden weitergegeben.

Der Einstieg in DDD kann verwirrend sein. Wo wir DDD doch einsetzen, um die Komplexität von Projekten zu reduzieren, stellt Vlad DDD konsequenterweise auf eine Art und Weise vor, die die Komplexität des Themas an sich verringert. Und er macht mehr, als nur die Prinzipien von DDD vorzustellen. Im hinteren Teil des Buchs sind ein paar wichtige Praktiken beschrieben, die sich aus DDD entwickelt haben, wie zum Beispiel das EventStorming, der Umgang mit der Weiterentwicklung des Business-Fokus oder der Organisation an sich und deren Einfluss auf die Software, und es wird besprochen, wie DDD und Microservices zusammenpassen und wie Sie beides mit wohlbekannten Software-Patterns integrieren können. Ich denke, dass Einführung in Domain-Driven Design ein ausgezeichneter Einstieg für Neulinge sein wird, aber auch erfahrene Praktiker und Praktikerinnen davon sehr profitieren werden.

– Julie Lerman,

Software-Coach, O’Reilly-Autorin

und schon lange überzeugte DDD-Advokatin

Vorwort

Ich erinnere mich noch lebhaft an den Tag, an dem ich meinen ersten Job in der Softwareentwicklung antrat. Ich war gleichzeitig euphorisch und eingeschüchtert. Nachdem ich während meiner Zeit auf dem Gymnasium Software für lokale Firmen zusammengehackt hatte, wollte ich nun unbedingt ein »richtiger Programmierer« werden und Code für eine der größten Outsourcing-Firmen des Landes schreiben.

In meinen ersten Tagen dort zeigten mir meine neuen Kolleginnen und Kollegen die wichtigsten Dinge. Nach dem Einrichten des Firmen-E-Mail-Kontos und dem Vertrautmachen mit dem Zeiterfassungssystem ging es endlich um die interessanten Dinge: die Coding-Richtlinien und -Standards des Unternehmens. Mir wurde gesagt: »Hier schreiben wir immer gut designten Code, und wir verwenden Schichtenarchitektur.« Wir gingen die Definition jeder der drei Schichten durch – Datenzugriffs-, Business-Logik- und Präsentationsschicht – und sprachen dann über die Technologien und Frameworks für die jeweiligen Anforderungen der Schichten. Damals wurden Daten mit dem Microsoft SQL Server 2000 gespeichert, der mithilfe von ADO.NET in die Datenzugriffsschicht integriert wurde. Die Präsentationsschicht setzte wahlweise auf WinForms für Desktopanwendungen oder auf ASP.NET WebForms für das Web. Wir verbrachten recht viel Zeit mit diesen beiden Schichten, und es verwirrte mich, dass die Business-Logik-Schicht kaum Aufmerksamkeit erhielt:

»Aber was ist mit der Business-Logik-Schicht?«

»Die ist ganz einfach. Da implementierst du die Business-Logik.«

»Aber was ist Business-Logik?«

»Ach, Business-Logik sind all die Schleifen und if-else-Anweisungen, die du brauchst, um die Anforderungen zu erfüllen.«

An diesem Tag begann meine Forschungsreise, auf der ich herausfinden wollte, was genau Business-Logik ist und wie sie eigentlich in gut designtem Code implementiert werden sollte. Es dauerte mehr als drei Jahre, bis ich endlich die Antwort fand.

Sie lag in Eric Evans bahnbrechendem Buch Domain-Driven Design: Tackling Complexity in the Heart of Software. Es stellte sich heraus, dass ich nicht falschlag. Business-Logik ist tatsächlich wichtig – sie ist das Herz der Software! Leider dauerte es aber weitere drei Jahre, bis ich die Weisheiten verstand, die Eric mir mitteilte. Das Buch ist sehr fortgeschritten, und die Tatsache, dass Englisch nur meine Drittsprache ist, hat dabei nicht geholfen.

Schließlich fügte sich aber alles zusammen, und ich schloss meinen Frieden mit Domain-Driven Design (DDD). Ich lernte die Prinzipien und Patterns von DDD kennen sowie die Feinheiten des Modellierens und Implementierens der Business-Logik und wie man die Komplexität im Herzen der Software angeht, die ich gerade baute. Trotz der Schwierigkeiten war es das wert. Meine Karriere verlief durch Domain-Driven Design deutlich anders.

Warum ich dieses Buch geschrieben habe

In den letzten zehn Jahren habe ich meinen Kolleginnen und Kollegen bei den unterschiedlichsten Firmen Domain-Driven Design vorgestellt und Kurse online wie offline darüber gehalten. Die Perspektive des Lehrers hat mir nicht nur dabei geholfen, mein Wissen zu vertiefen, sondern auch, die Art und Weise zu optimieren, wie ich die Prinzipien und Patterns von Domain-Driven Design vermittle.

Wie so oft ist Unterrichten noch herausfordernder als Lernen. Ich bin ein großer Fan der Arbeit und der Vorträge von Eliyahu M. Goldratt (https://de.wikipedia.org/wiki/Eliyahu_M._Goldratt). Eliyahu hat gerne erzählt, dass selbst die komplexesten Systeme inhärent einfach sind, wenn man sie aus dem richtigen Winkel betrachtet. In all den Jahren, in denen ich DDD lehre, war ich auf der Suche nach einem Modell der Methodik, die die inhärente Einfachheit von Domain-Driven Design aufzeigt.

Dieses Buch ist das Ergebnis meiner Bemühungen. Sein Ziel ist es, Domain-Driven Design zu demokratisieren – es leichter zu verstehen und es besser einsetzen zu können. Ich glaube, dass die DDD-Methodik von unschätzbarem Wert ist, insbesondere wenn Sie moderne Softwaresysteme entwerfen. Dieses Buch wird Ihnen genug Werkzeuge an die Hand geben, um bei Ihrer tagtäglichen Arbeit mit dem Anwenden von Domain-Driven Design beginnen zu können.

Wer dieses Buch lesen sollte

Ich denke, dass das Wissen um Prinzipien und Patterns von Domain-Driven Design für die Softwareentwicklung auf allen Ebenen nützlich ist – beim Einstieg in die Entwicklung, während man besser wird bis hin zur Arbeit auf Leitungsebene. DDD stellt nicht nur Werkzeuge und Techniken zum Modellieren und effektiven Implementieren von Software bereit, es beleuchtet zudem einen häufig übersehenen Aspekt der Softwareentwicklung – den Kontext. Ausgestattet mit dem Wissen über das Business-Problem des Systems, werden Sie beim Wählen einer passenden Lösung viel effektiver sein, einer Lösung, die nicht zu sehr vereinfacht noch zu »overengineert« ist, sondern die Bedürfnisse und Ziele des Business erfüllt.

Domain-Driven Design ist für die Softwarearchitektur sogar noch wichtiger – und insbesondere für angehende Softwarearchitektinnen und -architekten. Seine Tools für strategische Designentscheidungen werden Ihnen dabei helfen, ein großes System in Komponenten zu unterteilen – Services, Microservices oder Subsysteme – und zu designen, wie die Komponenten miteinander interagieren, um ein System zu bilden.

Und schließlich werden wir in diesem Buch darüber sprechen, wie Sie nicht nur Software designen, sondern auch, wie Sie das Design parallel zu Änderungen im Business-Umfeld weiterentwickeln. Dieser wichtige Aspekt der Softwareentwicklung wird Ihnen dabei helfen, das Systemdesign mit der Zeit »in Form« zu halten und zu verhindern, dass es sich in einen Big Ball of Mud verwandelt.

Übersicht über das Buch

Dieses Buch ist in vier Teile unterteilt: strategisches Design, taktisches Design, DDD in der Praxis und die Beziehung zwischen DDD und anderen Methodiken und Patterns. In Teil I stellen wir Werkzeuge und Techniken für Entscheidungen zu umfassenden Designfragen vor. In Teil II konzentrieren wir uns auf den Code – die verschiedenen Wege, die Business-Logik in ein System zu integrieren. Teil III behandelt Techniken und Strategien für das Anwenden von DDD auf reale Projekte. Und in Teil IV geht es ebenfalls um Domain-Driven Design, nun aber im Kontext anderer Methodiken und Patterns.

Dies werden Sie im jeweiligen Kapitel finden:

Kapitel 1

setzt den Rahmen für ein Softwareentwicklungsprojekt: die Fachdomäne, ihre Ziele und wie die Software sie unterstützen soll.

Kapitel 2

stellt die Idee einer »Ubiquitous Language« vor: die Praktik von Domain-Driven Design für eine effektive Kommunikation und Wissensvermittlung.

Kapitel 3

behandelt den Umgang mit der Komplexität von Fachdomänen und das Designen der High-Level-Architektur-Komponenten des Systems: Bounded Contexts.

Kapitel 4

untersucht die verschiedenen Patterns (Entwurfsmuster) zum Organisieren der Kommunikation und zur Integration der Bounded Contexts.

In

Kapitel 5

beginnt der Einstieg in die Implementierungs-Patterns für die Business-Logik mit zwei Patterns, die für die einfache Business-Logik gedacht sind.

In

Kapitel 6

geht es weiter zu komplexer Business-Logik und dem dazu passenden Domain Model Pattern.

Kapitel 7

ergänzt die Zeit-Perspektive und es führt einen noch fortgeschritteneren Weg zum Modellieren und Implementieren von Business-Logik ein: das Event-Sourced Domain Model.

In

Kapitel 8

verschiebt sich der Fokus hin zu einer höheren Ebene, und es werden drei Architektur-Patterns zum Strukturieren von Komponenten beschrieben.

Kapitel 9

stellt die Patterns vor, die zum Orchestrieren der Arbeit der Systemkomponenten erforderlich sind.

In

Kapitel 10

werden die bisher besprochenen Patterns zu einer Handvoll einfacher Faustregeln zusammengeführt, die das Treffen von Designentscheidungen vereinfachen.

Kapitel 11

schaut sich das Softwaredesign im zeitlichen Verlauf an und beschreibt, wie es sich im Rahmen seiner Lebensspanne verändern und weiterentwickeln sollte.

Kapitel 12

stellt das EventStorming vor: ein Low-Tech-Workshop für das effektive Teilen von Wissen, den Aufbau eines gemeinsamen Verständnisses und das Designen von Software.

Kapitel 13

führt die Schwierigkeiten auf, denen Sie sich eventuell gegenübersehen, wenn Sie Domain-Driven Design in bestehende Projekte einführen.

In

Kapitel 14

geht es um die Beziehung zwischen dem Microservices-Architekturstil und Domain-Driven Design: wo die Unterschiede liegen und wo sie sich gegenseitig ergänzen.

Kapitel 15

schaut sich Patterns und Werkzeuge von Domain-Driven Design im Kontext der Event-Driven Architecture an.

In

Kapitel 16

wechseln wir schließlich noch von operationalen Systemen hin zu analytischen Datenmanagementsystemen und sprechen über das Zusammenspiel von Domain-Driven Design und der Data Mesh Architecture.

Alle diese Kapitel enden mit einer Reihe von Übungsfragen, die Sie beim Lernen unterstützen sollen. Manche der Fragen beziehen sich auf die fiktive Firma »Wolf-Desk«, um die verschiedenen Aspekte von Domain-Driven Design aufzuzeigen. Bitte lesen Sie sich die folgende Beschreibung von WolfDesk durch und werfen Sie auch gelegentlich erneut einen Blick darauf, wenn Sie relevante Übungsaufgaben beantworten wollen.

Beispieldomäne: WolfDesk

WolfDesk bietet ein Ticket-Management-System für Help Desks als Service an. Muss Ihr Start-up Ihren Kundinnen und Kunden Unterstützung bieten können, ist es in Nullkommanichts möglich, mithilfe von WolfDesk loszulegen.

WolfDesk nutzt ein anderes Bezahlmodell als seine Mitbewerber. Statt einen Betrag pro User zu verlangen, erlaubt es seinen Tenants (dt. Mandanten bzw. Unternehmenskunden, die die Software für den Support ihrer Kunden einsetzen), so viele Tickets wie nötig anzulegen. Die Kosten sind dann abhängig von der Anzahl der Support-Tickets, die pro Berechnungszeitraum geöffnet werden. Es gibt keinen Minimalbetrag, und es gibt automatische Volumenrabatte ab bestimmten Mengen an Tickets pro Monat: 10 % für das Öffnen von mehr als 500 Tickets, 20 % für mehr als 750 Tickets und 30 % für mehr als 1.000 Tickets.

Um zu verhindern, dass die Tenants das Geschäftsmodell missbrauchen, stellt der Algorithmus für den Ticket-Lebenszyklus sicher, dass inaktive Tickets automatisch geschlossen werden, sodass Kunden, die den Service nutzen, dazu angehalten sind, neue Tickets zu öffnen, wenn weitere Hilfe notwendig ist. Zudem implementiert WolfDesk ein Fraud Detection System, das Nachrichten analysiert und Fälle aufdeckt, in denen nicht miteinander in Zusammenhang stehende Themen im selben Ticket diskutiert werden.

Damit die Tenants bei ihrer Support-Arbeit unterstützt werden, hat WolfDesk ein »Support Autopilot«-Feature implementiert. Der Autopilot analysiert neue Tickets und versucht automatisch, eine passende Lösung in der Ticket-Historie zu finden. Die Funktionalität erlaubt es, die Nutzungsdauer der Tickets weiter zu verringern, und die Kunden werden dazu angehalten, neue Tickets für weitere Fragen zu öffnen.

WolfDesk implementiert alle denkbaren Sicherheitsstandards und -maßnahmen, um die User ihrer Tenants zu authentifizieren und zu autorisieren. Zudem können die Tenants ein Single Sign-On (SSO) auf Basis ihrer bestehenden Benutzerverwaltung konfigurieren.

Die Administrationsoberfläche erlaubt den Tenants, die möglichen Werte für die Ticket-Kategorien und eine Liste der Produkte zu konfigurieren.

Um neue Tickets nur während der Arbeitszeiten an die Support Agents des Tenants zu routen, kann man deren Arbeitszeiten in WolfDesk erfassen.

Da WolfDesk seine Services ohne Mindestgebühr anbietet, muss es seine Infrastruktur so optimieren, dass die Kosten beim Anlegen neuer Tenants minimiert werden. Dazu setzt WolfDesk auf Serverless Computing, sodass es seine Rechenressourcen flexibel an die Menge an aktiven Tickets anpassen kann.

In diesem Buch verwendete Konventionen

Die folgenden typografischen Konventionen werden in diesem Buch eingesetzt:

Kursiv

Kennzeichnet neue Begriffe, URLs, E-Mail-Adressen, Dateinamen und Dateiendungen.

Nichtproportionalschrift

Für Programmlistings, aber auch für Codefragmente in Absätzen, wie zum Beispiel Variablen- oder Funktionsnamen, Datenbanken, Datentypen, Umgebungsvariablen, Anweisungen und Schlüsselwörter.

Dieses Symbol steht für eine allgemeine Anmerkung.

Der Einsatz von Codebeispielen

Zusätzliches Material (Codebeispiele, Übungen und so weiter) finden Sie (auf Englisch) zum Herunterladen auf https://learning-ddd.com.

Alle Beispiele in diesem Buch sind in C# implementiert. Im Allgemeinen handelt es sich bei den Codebeispielen in den Kapiteln um Auszüge, die die besprochenen Konzepte aufzeigen sollen.

Natürlich sind die in diesem Buch behandelten Konzepte und Techniken nicht auf C# oder einen objektorientierten Ansatz beschränkt. Alles ist auch für andere Sprachen und andere Programmierparadigmen relevant. Sie dürfen daher gerne die Beispiele aus dem Buch in Ihrer Lieblingssprache implementieren und mir zukommen lassen. Ich werde sie dann auf der Website zum Buch ergänzen.

Haben Sie eine technische Frage oder ein Problem beim Einsatz der Codebeispiele, schreiben Sie bitte eine Mail an [email protected].

Dieses Buch soll Ihnen bei der Arbeit helfen. Generell können Sie die Codebeispiele in diesem Buch in Ihren Programmen und Ihrer Dokumentation nutzen. Sie müssen uns nicht um Erlaubnis fragen, sofern Sie nicht einen signifikanten Anteil des Codes veröffentlichen. So erfordert zum Beispiel das Schreiben eines Programms, das diverse Codeschnipsel aus diesem Buch nutzt, keine Erlaubnis. Das Verkaufen oder Bereitstellen von Beispielen aus diesem Buch benötigt hingegen eine Erlaubnis. Beantworten Sie eine Frage, indem Sie dieses Buch zitieren und Beispielcode daraus nutzen, benötigen Sie keine Erlaubnis. Übernehmen Sie einen deutlichen Teil des Beispielcodes für Ihre Produktdokumentation, müssen Sie fragen.

Wir freuen uns über eine Quellenangabe, verlangen sie aber nicht unbedingt. Zu einer Quellenangabe gehören normalerweise Titel, Autor, Verlag und ISBN – zum Beispiel: »Learning Domain-Driven Design by Vlad Khononov (O’Reilly). Copyright 2022 Vladislav Khononov, 978-1-098-10013-1.«

Wenn Sie das Gefühl haben, dass Sie die Codebeispiele über die Grenzen des Erlaubten hinaus einsetzen, können Sie uns über [email protected] erreichen.

Danksagung

Ursprünglich hatte dieses Buch den Titel »What Is Domain-Driven Design?« und wurde 2019 als Report veröffentlicht. Einführung in Domain-Driven Design hätte das Licht der Welt nie ohne diesen Report erblickt, und ich bin denjenigen zu großem Dank verpflichtet, die »What Is Domain-Driven Design?« möglich gemacht haben: Chris Guzikowski, Ryan Shaw und Alicia Yound.1

Dieses Buch wäre durch den Content Director und Diversity Talent Lead Melissa Duffield ebenso wenig möglich gewesen, da sie für dieses Projekt gekämpft und es realisiert hat. Vielen Dank für all die Hilfe, Melissa!

Jill Leonard war Development Editor, Project Manager und Head Coach für dieses Buch. Ihre Rolle an diesem Buch kann gar nicht hoch genug gelobt werden. Jill – vielen Dank für all die harte Arbeit und deine Hilfe! Ein besonderer Dank dafür, dass du meine Motivation hochgehalten hast, auch als ich mit dem Gedanken spielte, meinen Namen zu ändern und ins Ausland abzutauchen.

Ein großer Dank gebührt dem Produktionsteam, durch die das Buch nicht nur geschrieben, sondern auch gelesen werden konnte: Kristen Brown, Audrey Doyle, Kate Dullea, Robert Romano und Katherine Tozer. Ich möchte hier auch dem gesamten Team von O’Reilly für seine tolle Arbeit danken. Die Arbeit mit euch ist ein Traum!

Vielen Dank an all die Menschen, die ich interviewt und mit denen ich mich beraten habe: Zófia Herendi, Scott Hirleman, Trond Hjorteland, Mark Lisker, Chris Richardson, Vaughn Vernon und Ivan Zakrevsky. Vielen Dank für eure Weisheit und dafür, dass ihr da wart, als ich Hilfe brauchte!

Ein besonderer Dank geht an das Team der Reviewer, die die frühen Entwürfe gelesen und mir dabei geholfen haben, die finale Version zu schaffen: Julie Lerman, Ruth Malan, Diana Montalion, Andrew Padilla, Rodion Promyshlennikov, Viktor Pshenitsyn, Alexei Torunov, Nick Tune, Vasiliy Vasilyuk und Rebecca Wirfs-Brock. Eure Unterstützung, euer Feedback und eure Kritik haben unfassbar viel geholfen. Danke sehr!

Auch möchte ich Kenny Baas-Schwegler, Alberto Brandolini, Eric Evans, Marco Heimeshoff, Paul Rayner, Mathias Verraes und dem Rest der tollen Domain-Driven Design Community danken. Ihr wisst, wer ihr seid. Ihr seid meine Lehrer und Mentorinnen. Vielen Dank, dass ihr euer Wissen per Social Media, Blogs und Konferenzen weitergebt!

Den größten Dank schulde ich meiner lieben Frau Vera, die mich immer bei meinen verrückten Projekten unterstützt und versucht, mich von Dingen fernzuhalten, die mich vom Schreiben abhalten. Ich verspreche, jetzt auch endlich den Keller aufzuräumen. Ganz bestimmt!

Schließlich möchte ich dieses Buch unserer lieben Galina Ivanovna Tyumentseva widmen, die mich in diesem Projekt so sehr unterstützt hat und die leider während des Schreibens des Buchs von uns gegangen ist. Wir werden immer an dich denken.

#AdoptDontShop

Einleitung

Softwareentwicklung ist hart. Um dabei erfolgreich zu sein, müssen wir kontinuierlich Neues lernen – sei es das Ausprobieren neuer Sprachen, das Erforschen neuer Technologien oder das Schritthalten mit neuen, beliebten Frameworks. Aber der schwerste Aspekt Ihres Jobs ist es nicht, jede Woche ein neues JavaScript-Framework zu erlernen, es kann viel herausfordernder sein, neue Fachdomänen zu verstehen.

In unserer Karriere ist es nicht ungewöhnlich, Software für viele verschiedene Fachdomänen zu entwickeln: Finanzsysteme, medizinische Software, Online-Retailer, Marketing und viele andere. Das ist es auch, was unseren Job von vielen anderen Berufen unterscheidet. Menschen, die in anderen Branchen arbeiten, sind oft überrascht, wie viel Lernen bei der Softwareentwicklung erforderlich ist, insbesondere wenn man den Arbeitsplatz wechselt.

Schafft man es nicht, die Fachdomäne zu verstehen, führt das zu einer nicht so optimalen Implementierung der Business-Software. Leider ist das nicht ungewöhnlich. Studien besagen, dass ungefähr 70 % der Softwareprojekte nicht pünktlich fertiggestellt werden, teurer als gedacht sind oder nicht den Anforderungen der Kunden entsprechen. Mit anderen Worten – ein großer Teil der Softwareprojekte ist kein Erfolg. Dieses Problem ist so umfassend und tiefgehend, dass wir sogar einen Begriff dafür haben: die Softwarekrise.

Der Begriff Softwarekrise tauchte schon 1968 auf.1 Man sollte vielleicht annehmen, dass sich die Dinge in den seitdem vergangenen 50 Jahren verbessert hätten. Unzählige Ansätze, Methodiken und Disziplinen wurden geschaffen, um die Softwareentwicklung effektiver zu machen: das Agile Manifest, Extreme Programming, Test-Driven Development, High-Level-Sprachen, DevOps und viele andere. Aber leider hat sich nicht viel getan. Projekte schlagen immer noch ziemlich häufig fehl, und die Softwarekrise ist immer noch da.

Es wurden viele Studien durchgeführt, um die Gründe für die am häufigsten anzutreffenden Projektfehlschläge zu untersuchen.2 Auch wenn die Forschung es nicht geschafft hat, eine einzelne Ursache zu finden, geht es in den meisten Fällen um ein gemeinsames Thema: Kommunikation. Kommunikationsprobleme, die Projekte ausbremsen, können sich auf unterschiedliche Art und Weise bemerkbar machen – zum Beispiel durch unklare Anforderungen, nicht eindeutige Projektziele oder eine ineffiziente Koordination der Arbeit zwischen verschiedenen Teams. Auch hier haben wir im Laufe der Jahre versucht, die Inter- und Intra-Team-Kommunikation durch neue Kommunikationsmöglichkeiten, -prozesse und -medien zu verbessern. Leider hat sich die Erfolgsrate unserer Projekte immer noch nicht groß verändert.

Domain-Driven Design (DDD) verspricht, die eigentliche Ursache für fehlschlagende Softwareprojekte anders anzugehen. Effektive Kommunikation ist das zentrale Thema der Werkzeuge und Praktiken von Domain-Driven Design, die Sie in diesem Buch kennenlernen werden. DDD lässt sich in zwei Teile unterteilen: Strategie und Taktik.

Die strategischen Werkzeuge von DDD werden verwendet, um Fachdomänen und Business-Strategien zu analysieren und um ein gemeinsames Verständnis des Business zwischen den verschiedenen Beteiligten zu schaffen. Dieses Wissen über die Fachdomäne nutzen wir zudem, um Designentscheidungen auf hoher Ebene zu treffen – Systeme in Komponenten zu unterteilen und ihre Integrations-Patterns zu definieren.

Die taktischen Tools von Domain-Driven Design widmen sich einem anderen Aspekt der Kommunikationsprobleme. Sie ermöglichen uns, Code so zu schreiben, dass er die Fachdomäne widerspiegelt, ihre Ziele unterstützt und die Sprache des Business spricht.

Sowohl die strategischen wie auch die taktischen Patterns und Praktiken von DDD verbinden Softwaredesign mit seiner Fachdomäne. Daher stammt der Name: (Business) Domain-Driven (Software) Design.

Domain-Driven Design ermöglicht es zwar nicht, das Wissen über neue JavaScript-Bibliotheken wie bei Matrix direkt in Ihr Hirn zu pflanzen, aber Sie werden so bei der Softwareentwicklung deutlich effektiver, weil das Verstehen der Fachdomäne einfacher wird und die Designentscheidungen durch die Business-Strategie geleitet werden. Wie Sie in den folgenden Kapiteln lernen werden, wird das Betreuen und Weiterentwickeln des Systems für zukünftige Business-Anforderungen umso besser, je enger die Verbindung zwischen Softwaredesign und Business-Strategie ist – was letztendlich zu erfolgreicheren Softwareprojekten führt.

Beginnen wir unsere Reise durch das Domain-Driven Design, indem wir uns die strategischen Patterns und Praktiken anschauen.

TEIL I

Strategisches Design

Es ist nicht sinnvoll, über die Lösung zu sprechen, bevor wir uns über das Problem einig geworden sind, und ebenso wenig, über die Implementierungsschritte zu sprechen, bevor wir über die Lösung Klarheit haben.

– Efrat Goldratt-Ashlag1

Die Methodik von Domain-Driven Design (DDD) lässt sich in zwei große Bereiche unterteilen: in das strategische und das taktische Design. Der strategische Aspekt von DDD dreht sich um das Beantworten der Fragen nach dem »Was?« und dem »Warum?« – was für Software wir bauen und warum wir sie bauen. Im taktischen Teil geht es um das »Wie?« – wie jede Komponente implementiert wird.

Beginnen wir unsere Reise mit dem Erforschen von DDD-Patterns und -Prinzipien des strategischen Designs:

In

Kapitel 1

werden Sie lernen, die Business-Strategie eines Unternehmens zu analysieren: Welche Werte bietet es seinen Kundinnen und Kunden, und wie konkurriert es mit anderen Firmen in der Branche? Wir werden kleinere Business-Bausteine ermitteln, deren strategischen Wert herausfinden und analysieren, wie sie die verschiedenen Designentscheidungen für die Software beeinflussen.

Kapitel 2

stellt die grundlegende Praktik von Domain-Driven Design vor, mit der man die Fachdomäne zu verstehen lernt: die

Ubiquitous Language

(die »allgegenwärtige Sprache«). Sie werden lernen, wie Sie eine Ubiquitous Language kultivieren und wie Sie sie nutzen, um ein gemeinsames Verständnis zwischen allen Projektbeteiligten zu fördern.

Kapitel 3

dreht sich um ein weiteres zentrales Werkzeug von Domain-Driven Design: das

Bounded Context Pattern

. Sie werden erfahren, warum dieses Tool ausgesprochen wichtig ist, um eine Ubiquitous Language zu kultivieren, und wie Sie es nutzen, um gewonnenes Wissen in ein Modell der Fachdomäne umzuwandeln. Schließlich werden wir Bounded Contexts verwenden, um die größeren Komponenten des Softwaresystems zu designen.

In

Kapitel 4

werden Sie die technischen und sozialen Beschränkungen kennenlernen, die Einfluss darauf haben, wie Systemkomponenten integriert werden können. Dazu stelle ich Integrations-Patterns vor, die unterschiedliche Situationen und Beschränkungen angehen. Wir werden darüber sprechen, wie jedes Pattern die Zusammenarbeit zwischen den Teams zur Softwareentwicklung und das Design der Komponenten-APIs beeinflusst.

Am Ende des Kapitels stellen wir eine Context Map vor – eine grafische Darstellung, die die Kommunikation zwischen den Bounded Contexts eines Systems aufzeigt und einen Überblick über die Integrations- und Kollaborationslandschafen des Projekts ermöglicht.

KAPITEL 1

Fachdomänen analysieren

Wenn Sie so sind wie ich, lieben Sie das Schreiben von Code: Sie lösen komplexe Probleme, sorgen für elegante Lösungen und erschaffen ganz neue Welten, indem Sie sorgfältig deren Regeln, Strukturen und Verhaltensweisen formen. Ich glaube, dass es das ist, was Sie am Domain-Driven Design (DDD) interessiert: Sie wollen in Ihrem Handwerk besser werden. In diesem Kapitel geht es allerdings nicht um das Schreiben von Code. Hier werden Sie lernen, wie Firmen funktionieren: warum es sie gibt, welche Ziele sie verfolgen und wie ihre Strategien zum Erreichen dieser Ziele aussehen.

Wenn ich dieses Material in meinen Kursen zum Domain-Driven Design unterrichte, fragen viele Studierende tatsächlich: »Müssen wir das alles wissen? Wir schreiben Software – aber wir führen keine Firma.« Die Antwort auf diese Frage ist ein klares »Ja«. Um eine effektive Lösung zu entwerfen und zu bauen, müssen Sie das Problem verstehen – in unserem Kontext das Softwaresystem, das wir bauen müssen. Um es zu verstehen, müssen Sie den Kontext verstehen, in dem es existiert – die Business-Strategie der Organisation und welchen Wert sie mit dem Bauen der Software schaffen will.

In diesem Kapitel werden Sie Werkzeuge von Domain-Driven Design zum Analysieren der Fachdomäne einer Firma und ihrer Strukturen kennenlernen – ihre Core, Supporting und Generic Subdomains. Dieses Material ist die Grundlage für das Designen von Software. In den restlichen Kapiteln werde ich die verschiedenen Wege vorstellen, auf denen diese Konzepte Einfluss auf das Softwaredesign haben.

Was ist eine Fachdomäne?

Eine Fachdomäne definiert die Hauptaktivitäten einer Firma. Im Allgemeinen ist es der Service, den die Firma ihren Kundinnen und Kunden anbietet, zum Beispiel:

FedEx bietet eine Kurierzustellung.

Starbucks ist vor allem für seinen Kaffee bekannt.

Walmart ist eines der bekanntesten Einzelhandelsunternehmen.

Eine Firma kann in mehreren Fachdomänen tätig sein. So ist Amazon Einzelhändler, bietet aber auch Cloud-Computing-Services. Uber ist eine Rideshare-Firma, die zudem Essen ausliefert und bei der man Fahrräder ausleihen kann.

Es ist wichtig, darauf hinzuweisen, dass Unternehmen ihre Fachdomänen häufig wechseln können. Ein klassisches Beispiel dafür ist Nokia, das im Lauf der Jahre in so unterschiedlichen Branchen wie Holzverarbeitung, Gummiverarbeitung, Telekommunikation und Mobilkommunikation unterwegs war.

Was ist eine Subdomain?

Um die Ziele einer Fachdomäne zu erreichen, muss ein Unternehmen in mehreren Subdomains (Unter- oder Teildomänen) agieren. Eine Subdomain ist ein kleinerer Bereich der Business-Aktivitäten. Alle Subdomains einer Firma zusammen bilden ihre Fachdomäne – den Service, den sie ihren Kundinnen und Kunden bietet. Das Implementieren einer einzelnen Subdomain reicht nicht aus, damit ein Unternehmen erfolgreich ist – es ist nur ein Baustein im Gesamtsystem. Die Subdomains müssen miteinander interagieren, um die Ziele der Firma in ihrer Fachdomäne erreichen zu können. So mag Starbucks beispielsweise vor allem für seinen Kaffee bekannt sein, aber für den Aufbau einer erfolgreichen Kaffeehauskette muss man mehr können, als nur zu wissen, wie man großartigen Kaffee macht. Sie müssen auch Räumlichkeiten an guten Standorten kaufen oder mieten, Personal einstellen und sich um die Finanzen kümmern – neben vielem anderen. Keine dieser Subdomains wird allein für ein profitables Unternehmen sorgen. Alle zusammen sind notwendig, damit sich eine Firma in ihrer einen oder ihren mehreren Fachdomänen behaupten kann.

Arten von Subdomains

So wie ein Softwaresystem unterschiedliche Architekturkomponenten zusammenführt – Datenbanken, Frontend-Anwendungen, Backend-Services und so weiter –, stehen Subdomains für unterschiedliche Strategien oder Business-Werte. Das Domain-Driven Design unterscheidet zwischen drei Arten von Subdomains: Core, Generic und Supporting. Schauen wir uns an, wie sie sich aus Sicht einer Firmenstrategie unterscheiden.

Core Subdomains

Eine Core Subdomain (zentrale Subdomain) ist das, was eine Firma anders als ihre Konkurrenten macht. Dazu kann das Entwickeln neuer Produkte oder Services gehören, aber auch das Verringern von Kosten durch Optimierung bestehender Prozesse.

Nehmen wir Uber als Beispiel. Zunächst hat die Firma mit dem Ridesharing eine neue Form des Personentransports angeboten. Als die Konkurrenz aufholte, fand Uber Wege, ihr Kerngeschäft zu optimieren und weiterzuentwickeln – zum Beispiel durch das Verringern von Kosten, indem Fahrgäste zusammengebracht wurden, die in die gleiche Richtung wollten.

Die Core Subdomains beziehen sich auf die Quintessenz von Uber – wie sich die Firma von ihren Mitbewerbern abhebt. Das ist ihre Strategie zum Bereitstellen eines besseren Service für die Kundinnen und Kunden und/oder das Maximieren ihrer Profitabilität. Um einen Wettbewerbsvorteil zu behalten, gehören zu den Core Subdomains Erfindungen, kluges Optimieren, Business-Know-how oder anderes geistiges Eigentum.

Schauen wir uns ein anderes Beispiel – den Ranking-Algorithmus von Google Search an. Aktuell ist die Werbeplattform von Google die Haupteinnahmequelle der Firma. Dabei ist Google Ads keine Subdomain, sondern stattdessen eine eigene Fachdomäne mit eigenen Subdomains, neben der noch der Cloud-Computing-Service (Google Cloud Platform), Produktivitäts- und Kollaborationstools (Google Workspaces) und andere Bereiche stehen, in denen Alphabet – Googles Muttergesellschaft – aktiv ist. Aber was ist nun mit Google Search und seinem Ranking-Algorithmus? Auch wenn die Suchmaschine kein zu bezahlender Dienst ist, agiert sie doch als größte Plattform zum Anzeigen von Google Ads. Die Fähigkeit, ausgesprochen gute Suchergebnisse zu liefern, sorgt für Traffic und ist damit eine wichtige Komponente der Ads-Plattform. Werden nur suboptimale Suchergebnisse geliefert, weil es einen Fehler im Algorithmus gibt oder ein Mittbewerber einen noch besseren Suchservice bietet, wird das die Einnahmen der Werbeplattform beeinträchtigen. Daher ist der Ranking-Algorithmus für Google eine Core Subdomain.

Komplexität Eine Core Subdomain, die sich leicht implementieren lässt, kann nur kurzzeitig für einen Wettbewerbsvorteil sorgen. Daher sind Core Subdomains naturgemäß komplex. Kehren wir nochmals zum Uber-Beispiel zurück: Die Firma hat nicht nur einen neuen Markt durch das Ridesharing geschaffen, es hat auch eine jahrzehntealte monolithische Architektur aufgebrochen – die Taxi-Branche –, indem sie gezielt Technologie eingesetzt hat. Weil Uber ihre Fachdomäne verstanden hat, war es dazu in der Lage, eine zuverlässigere und transparentere Transportmethode zu entwerfen. Es sollte hohe Einstiegshürden für das Core Business eines Unternehmens geben – die Konkurrenz sollte es schwer haben, die Lösung der Firma zu kopieren oder zu imitieren.

Gründe für einen Wettbewerbsvorteil Es ist wichtig, hervorzuheben, dass Core Subdomains nicht unbedingt technisch sein müssen. Nicht alle Business-Probleme lassen sich durch Algorithmen oder auf andere Weise technisch lösen. Der Wettbewerbsvorteil eines Unternehmens kann unterschiedliche Gründe haben.

Stellen Sie sich beispielsweise eine Juwelierin vor, die ihre Produkte online verkauft. Der Onlineshop ist wichtig, aber dabei handelt sich nicht um eine Core Subdomain – das ist das Schmuckdesign. Die Firma kann eine bestehende, fertige Onlineshop-Engine nutzen, aber sie kann nicht das Schmuckdesign outsourcen. Das Design ist der Grund dafür, dass Kundinnen und Kunden die Produkte der Juwelierin kaufen und die Marke in Erinnerung behalten.

Ein kniffligeres Beispiel: Denken Sie an eine Firma, die sich auf manuelle Betrugserkennung spezialisiert hat. Sie trainiert ihre Analysten und Analystinnen darin, fragliche Dokumente durchzugehen und mögliche Betrugsfälle zu kennzeichnen. Sie bauen das Softwaresystem, mit dem die Analysten arbeiten. Ist das eine Core Subdomain? Nein. Die Core Subdomain ist die Arbeit, die von den Mitarbeitenden erledigt wird. Das System, das Sie bauen, hat nichts mit der Betrugserkennung zu tun – es zeigt nur die Dokumente an und erfasst die Kommentare der Mitarbeitenden.

Core Subdomain versus Core Domain

Core Subdomains werden auch als Core Domains bezeichnet. So nutzt Eric Evans beispielsweise im Blue Book »Core Subdomain« und »Core Domain« synonym. Auch wenn der Begriff »Core Domain« häufiger verwendet wird, bevorzuge ich doch aus einer Reihe von Gründen die »Core Subdomain«. Zum einen ist es eine Subdomain, und ich möchte vermeiden, sie mit Fachdomänen zu verwechseln. Und zum anderen ist es, wie Sie in Kapitel 11 noch lernen werden, nicht unüblich, dass sich Subdomains mit der Zeit weiterentwickeln und ihre Art ändern. So kann sich beispielsweise eine Generic Subdomain zu einer Core Subdomain wandeln. Daher ist es klarer, davon zu sprechen, dass sich eine Generic Subdomain in eine Core Subdomain weiterentwickelt hat, als dass eine Generic Subdomain zu einer Core Domain geworden ist.

Generic Subdomains

Generic Subdomains sind Geschäftsaktivitäten, die alle Unternehmen auf die gleiche Art und Weise durchführen. Wie Core Subdomains sind Generic Subdomains im Allgemeinen komplex und nicht einfach zu implementieren. Aber Generic Subdomains liefern der Firma keinen Wettbewerbsvorteil. Es gibt hier keinen Grund für Innovation und Optimierung: Bewährte Implementierungen sind allgemein verfügbar, und alle Unternehmen setzen diese ein.

So müssen beispielsweise die meisten Systeme ihre Anwenderinnen und Anwender authentifizieren und autorisieren. Statt einen eigenen Authentifizierungsmechanismus zu erfinden, ist es viel sinnvoller, eine bestehende Lösung zu verwenden. Diese wird wahrscheinlich zuverlässiger und sicherer sein, weil sie schon von vielen anderen Firmen mit den gleichen Anforderungen getestet wurde.

Schauen wir uns auch nochmals das Beispiel der Juwelierin an, die ihre Produkte online verkauft. Schmuckdesign ist eine Core Subdomain, aber der Onlineshop ist eine Generic Subdomain. Der Einsatz der gleichen Onlineverkaufsplattform – der gleichen generischen Lösung – wie die Wettbewerber hat keinen Einfluss auf den Wettbewerbsvorteil der Juwelierin.

Supporting Subdomains

Wie der Name schon andeutet, unterstützen Supporting Subdomains das eigentliche Geschäft der Firma. Aber anders als Core Subdomains bieten Supporting Subdomains keinen Wettbewerbsvorteil.

Denken Sie beispielsweise an eine Onlinewerbeagentur, zu deren Core Subdomains das Abgleichen von Werbung und Besucherinnen und Besuchern, das Optimieren der Effektivität der Werbung und das Minimieren der Kosten für die Werbefläche gehören. Um in diesen Bereichen Erfolg zu haben, muss das Unternehmen sein kreatives Material katalogisieren. Die Art und Weise, wie die Firma ihre physischen kreativen Materialien – wie Banner und Landing Pages – ablegt und indexiert, hat keinen Einfluss auf ihren Profit. Es gibt in diesem Bereich nichts zu erfinden oder zu optimieren. Andererseits ist dieser Kreativkatalog für die Umsetzung der Werbemanagement- und Auslieferungssysteme des Unternehmens unerlässlich. Die Lösung zur Katalogisierung von Inhalten wird damit zu einer Supporting Subdomain des Unternehmens.

Supporting Subdomains unterscheiden sich in der Komplexität ihrer Business-Logik. Sie sind einfach. Ihre Business-Logik besteht vor allem aus Benutzeroberflächen zum Eingeben von Daten und ETL-Operationen (Extract, Transform, Load) – also sogenannten CRUD-Schnittstellen (Create, Read, Update, Delete). Diese Aktivitäten bieten der Firma keinen Wettbewerbsvorteil und erfordern daher keine hohen Einstiegshürden.

Subdomains vergleichen

Nachdem wir nun die drei Arten von Business Subdomains kennengelernt haben, wollen wir ihre Unterschiede aus verschiedenen Blickwinkeln betrachten und herausfinden, wie sie strategische Entscheidungen beim Softwaredesign beeinflussen.

Wettbewerbsvorteil

Nur Core Subdomains liefern einer Firma einen Wettbewerbsvorteil. Core Subdomains sind die Strategie einer Firma, mit der sie sich von ihren Wettbewerbern unterscheidet.

Generic Subdomains können laut Definition keinen Wettbewerbsvorteil liefern. Es handelt sich um generische Lösungen – die gleichen Lösungen, die auch von anderen Firmen eingesetzt werden.

Supporting Subdomains besitzen niedrige Einstiegshürden und können auch keinen Wettbewerbsvorteil liefern. Normalerweise wird sich eine Firma nicht darum scheren, wenn ein Wettbewerber ihre Supporting Subdomains kopiert – das hat keinen Einfluss auf die Wettbewerbsfähigkeit in der Branche. Ganz im Gegenteil: Aus strategischer Sicht wird das Unternehmen es bevorzugen, wenn seine Supporting Subdomains generische und direkt nutzbare Lösungen sind, weil es so keine eigene Implementierung entwerfen und bauen muss. Sie werden solche Fälle vom Umwandeln von Supporting Subdomains in Generic Subdomains (und andere mögliche Permutationen) in Kapitel 11 kennenlernen. Eine Fallstudie eines echten Szenarios wird in Anhang A vorgestellt.

Je komplexer die Probleme sind, die eine Firma angehen kann, desto mehr Wert kann sie bieten. Die komplexen Probleme sind nicht darauf beschränkt, Kundinnen und Kunden Services anzubieten. Ein komplexes Problem kann beispielsweise auch sein, das Business besser zu optimieren und effizienter zu gestalten. So ist es auch ein Wettbewerbsvorteil, den gleichen Service zu bieten wie ein Wettbewerber, dabei aber niedrigere operationale Kosten zu haben.

Komplexität

Aus eher technischer Sicht ist es wichtig, die Subdomains eines Unternehmens zu ermitteln, weil die verschiedenen Arten von Subdomains auch unterschiedliche Komplexität besitzen. Beim Designen von Software müssen wir Werkzeuge und Techniken wählen, die zur Komplexität der Business-Anforderungen passen. Daher ist es für das Designen einer stabilen Softwarelösung entscheidend, die Subdomains herauszufinden.

Die Business-Logik von Supporting Subdomains ist einfach. Es handelt sich um simple ETL-Operationen und CRUD-Schnittstellen, und die Business-Logik ist offensichtlich. Häufig geht es nicht über das Validieren von Eingabedaten oder das Umwandeln von Daten zwischen Strukturen hinaus.

Generic Subdomains sind viel komplexer. Es dürfte einen guten Grund geben, warum andere schon Zeit und Aufwand in das Lösen dieser Probleme gesteckt haben. Diese Lösungen sind weder einfach noch trivial. Denken Sie beispielsweise an Verschlüsselungsalgorithmen oder Authentifizierungsmechanismen.

Aus Sicht des verfügbaren Wissens sind Generic Subdomains »bekannte Unbekannte«. Es handelt sich um Dinge, von denen Sie wissen, dass Sie sich damit nicht genauer auskennen. Zudem ist dieses Wissen problemlos verfügbar. Sie können entweder auf branchenweit akzeptierte Best Practices zurückgreifen oder bei Bedarf eine Beraterin oder einen Spezialisten auf diesem Gebiet engagieren, die dabei helfen können, eine eigene Lösung zu entwerfen.

Core Subdomains sind komplex. Sie sollten für Wettbewerber so schwer wie möglich zu kopieren sein – die Profitabilität der Firma hängt davon ab. Darum versuchen Unternehmen aus strategischer Sicht, komplexe Probleme mithilfe ihrer Core Subdomains zu lösen.

Manchmal mag es schwierig sein, zwischen Core und Supporting Subdomain zu unterscheiden. Die Komplexität ist da eine nützliche Richtschnur. Fragen Sie sich, ob die Subdomain zu einem Nebengeschäft umgewandelt werden kann. Würde jemand dafür bezahlen? Wenn das der Fall ist, handelt es sich um eine Core Subdomain. Ähnliches gilt für die Unterscheidung zwischen Supporting und Generic Subdomains: Wäre es einfacher und günstiger, Ihre eigene Implementierung zusammenzuschrauben, statt eine externe zu integrieren? Wenn ja, handelt es sich um eine Supporting Subdomain.

Aus technischerer Sicht ist es wichtig, die Core Subdomains herauszufinden, deren Komplexität das Softwaredesign beeinflussen wird. Wie schon erwähnt, ist eine Core Subdomain nicht notwendigerweise mit Software verbunden. Eine weitere nützliche Richtschnur für das Ermitteln von softwarebezogenen Core Subdomains ist das Bestimmen der Komplexität der Business-Logik, die Sie modellieren und im Code implementieren müssen. Spiegelt die Business-Logik CRUD-Schnittstellen für die Dateneingabe wider, oder müssen Sie komplexe Algorithmen und Geschäftsprozesse implementieren, die durch komplexe Business-Regeln und Invarianten orchestriert werden? Im ersten Fall ist das ein Zeichen für eine Supporting Subdomain, während der zweite Fall typisch für eine Core Subdomain ist.

Das Diagramm in Abbildung 1-1 zeigt das Verhältnis zwischen den drei Arten von Subdomains anhand der Business-Abgrenzung und der Komplexität der Business-Logik. Die Schnittmenge zwischen Supporting und Generic Subdomains ist ein Graubereich – sie kann beides sein. Gibt es eine generische Lösung für die Funktionalität einer Supporting Subdomain, hängt die Art der Subdomain davon ab, ob es einfacher und/oder günstiger ist, die generische Lösung zu implementieren, statt die Funktionalität komplett selbst zu bauen.

Abbildung 1-1: Die Business-Abgrenzung und die Komplexität der Business-Logik der drei Arten von Subdomains

Volatilität

Wie schon erwähnt, können sich Core Subdomains häufig ändern. Lässt sich ein Problem auf Anhieb lösen, bietet die Lösung vermutlich keinen guten Wettbewerbsvorteil – andere Firmen werden schnell aufholen. Konsequenterweise entwickeln sich Lösungen für Core Subdomains weiter. Es müssen unterschiedliche Implementierungen ausprobiert, verbessert und optimiert werden. Zudem ist die Arbeit an Core Subdomains niemals getan. Firmen erneuern Core Subdomains kontinuierlich und entwickeln sie weiter. Die Änderungen manifestieren sich entweder als neue Features oder als das Optimieren bestehender Funktionalität. In beiden Fällen ist die andauernde Weiterentwicklung der Core Subdomains für eine Firma unabdingbar, um ihren Wettbewerbern voraus zu sein.

Im Gegensatz zu den Core Subdomains ändern sich Supporting Subdomains nicht so häufig. Sie bieten der Firma keinen Wettbewerbsvorteil, und daher liefert die Weiterentwicklung einer Supporting Subdomain nur wenig Business-Wert, wenn man sie mit dem Aufwand, der in eine Core Subdomain investiert wird, vergleicht.

Trotz bestehender Lösungen können sich Generic Subdomains mit der Zeit ändern. Solche Änderungen sind Sicherheits-Patches, Fehlerkorrekturen oder völlig neue Lösungen für die generischen Probleme.

Lösungsstrategien

Core Subdomains ermöglichen der Firma, sich gegen andere Mitspieler in der Branche zu behaupten. Das ist eine geschäftskritische Verantwortung, aber heißt das, dass Supporting und Generic Subdomains nicht wichtig sind? Natürlich nicht. Das Unternehmen braucht alle Subdomains, die in seiner Fachdomäne zusammenarbeiten. Die Subdomains sind wie grundlegende Bausteine: Nehmen Sie einen weg, kann die gesamte Struktur zusammenbrechen. Daher können wir die inhärenten Eigenschaften der verschiedenen Arten von Subdomains nutzen, um Implementationsstrategien zum möglichst effizienten Implementieren jeder Art von Subdomain zu finden.

Core Subdomains müssen in-house implementiert werden. Sie können nicht gekauft oder übernommen werden – das würde die Idee des Wettbewerbsvorteils unterminieren, da die Wettbewerber das Gleiche tun könnten.

Es wäre auch nicht klug, die Implementierung einer Core Subdomain auszulagern. Es handelt sich um eine strategische Investition. Es ist nicht nur riskant, am falschen Ende bei einer Core Subdomain zu sparen, es kann langfristig auch fatale Folgen haben: beispielsweise unwartbare Codebasen, die die Ziele der Firma nicht unterstützen können. Die besten Talente der Organisation sollten an den Core Subdomains arbeiten. Zudem ermöglicht eine In-house-Implementierung der Core Subdomains, schneller Änderungen an der Lösung vorzunehmen, sie weiterzuentwickeln und damit den Wettbewerbsvorteil in kürzerer Zeit auszubauen.

Da davon auszugehen ist, dass sich die Anforderungen von Core Subdomains häufig und regelmäßig ändern, muss die Lösung wartbar und leicht anpassbar sein. Daher ist für Core Subdomains eine Implementierung mit den ausgefeiltesten Entwicklungstechniken erforderlich.

Da Generic Subdomains schwierige, aber schon gelöste Probleme enthalten, ist es kostengünstiger, ein fertiges Produkt zu kaufen oder eine Open-Source-Lösung anzupassen, als Zeit und Aufwand in das In-house-Implementieren einer Generic Subdomain zu stecken.