Was ist DDD nun eigentlich?

Jemandem DDD (Domain-driven Design) zu erklären, scheint nicht immer ganz einfach zu sein. Entweder ist es zu technologielastig oder aber zu abstrakt, je nachdem mit welcher Zielgruppe man es zu tun hat.

Ist DDD …
–          ein Pattern?
–          eine Philosophie?
–          eine Architektur?
–          ein Entwicklungsansatz?
–          ein Prinzip?
–          eine Modeerscheinung?
–          Nichts (oder alles) davon.

DDD ist …
ein Denkansatz, mit dem man komplexe Software in den Griff bekommt, indem die fachlichen Anforderungen die Umsetzung steuern.

Komplexität ist aber nicht gleichbedeutend mit kompliziert oder umfangreich.

Sondern vielmehr: ” … ein System dessen Gesamtverhalten man selbst dann nicht eindeutig beschreiben kann, wenn man vollständige Informationen über seine Einzelkomponenten und ihre Wechselwirkungen besitzt. (Quelle: Wikipedia)

 

Der Kern von DDD

Sprache und Kommunikation

Jedes System oder jede Organisation besitzt seine eigene Sprache und Begriffe (Fachjargon), die im vollen Umfang nur vom System selbst verstanden werden.

Keine Sprache lässt sich vollständig in eine andere übersetzen. Es gehen immer mehr oder weniger wichtige Informationen verloren. Und fast jede Übersetzung ist eine Unterbrechung des Informationsflusses.

Kunde:
„Was heißt denn ‚validationState auf 7 setzen‘? Mir geht es darum, dass manche unserer Kunden gesperrt werden können und nicht mehr einkaufen dürfen!“

Software ist ausführbares Wissen.

Deshalb:
Vermeide es Begriffe zu benutzen, die vom Fachbereich nicht gesprochen werden.

Benutze den Fachjargon der Domäne. Sonst wird Wissen zur Vermutung.

 

Die Grenzen des Wissens

Beispiel 1 – Shop:

context2

Gleiche Begriffe werden oft von mehreren Fachbereichen verwendet. In den meisten Fällen beschreiben sie jedoch etwas völlig anderes. Dadurch werden sie global mehrdeutig.
Weitere Beispiele: Kunde, Adresse, Preis

Deshalb:
Jeder Fachbereich ist ein klar abgegrenzter Kontext, in dem die Bedeutung eines Wortes oder eines Konzepts eindeutig ist – und die Verantwortlichkeiten klar abgegrenzt sind.

Solange diese Grenzen nicht bekannt sind, macht es keinen Sinn, ein Modell dafür zu entwickeln. Und damit natürlich auch keine Datenbanktabellen, Klassen oder Frameworks festzulegen …

Sind die Grenzen festgelegt, folgt daraus, dass jeder Kontext sein eigenes Modell besitzt.
(mindestens eins!), keine komplexe Software besteht aus nur einem Modell.

Die Gesamtheit aller Kontexte, Modelle und ihrer Beziehungen untereinander ergibt die komplette Applikation. Visualisiert man das, ergibt es die Landkarte der Anwendung – mit ihren Grenzen, Beziehungen und Verbindungen.


Und wo ist der Kern?

Was macht unsere Software oder Teile davon so einzigartig, dass sie entwickelt werden muss und nicht bereits Bestehendes genommen werden kann? Was unterscheidet uns, was können wir besser als alle anderen?

Das ist der Kern.

Etwas, dass so fundamental ist, dass man es nicht durch andere Software ersetzen kann. Etwas, dem wir höchste Aufmerksamkeit und Sorgfalt und nur die besten Entwickler dran lassen sollten.
Im Businessjargon nennt man es USP.

Hinterlasse eine Antwort

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind markiert *

Du kannst folgende HTML-Tags benutzen: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Post Navigation