2016-01-19 10 views
8

Es wird oft gesagt, dass DDD (Domain-driven Design) eher für komplexe als für einfachere Domänen geeignet ist.DDD - Was ist eine komplexe Domäne?

Was kennzeichnet eine komplexe Domäne? (bitte seien Sie spezifischer als "es hat komplexe Geschäftsregeln");

Welche Beispiele für komplexe Domänen?

Wie kann ich eine Domäne als komplex klassifizieren (d. H. Für DDD geeignet) oder nicht?

+1

Ich würde sagen, nicht nur für * komplexe Domains * sondern auch für * ambitionierte Projekte, die ein langes Leben anstreben *. Die zweite Anweisung ignoriert die Komplexität. – fabriciorissetto

Antwort

5

Aus meiner Erfahrung 3 Wichtigste ist, dass Sie Ihre Domain-Komplex macht:

Größe

Big Domänen neigt Komplexität zu erhöhen. Die Handhabung und Koordination vieler Dinge ist immer schwierig.

Regeln und Invarianten

Domains (auch Domains mit nur ein paar begrenzten Kontext) kann unter Umständen viele Domain-Regeln und Invarianten und/oder viele Nuancen in ihren Anwendungsfällen und zu verarbeiten. Dies erhöht die Komplexität. Regeln, die viele Änderungen in einer Entität oder Interdomains-Ereignissen spammen, sind häufig die komplexen Geschäftsregeln.

Kontext

Kontext Komplexität ist schwer wihtout ein Beispiel zu erklären. Lassen Sie uns in die Tabelle eine Kontextkomplexität einfügen, die sich auf eine Entität mit dem Namen Product bezieht.

Abhängig vom Kontext; Eine Entität könnte verschiedene Dinge in Ihrer Domain bedeuten. Eine Entität bedeutet nicht das Gleiche für Factory-Kontext, Marketing-Kontext, Sales-Kontext, PostSales-Support-Kontext, etc.

Wenn die Daten, Benutzer-Cases, Prozess, Verhalten, usw. bezogen auf Einheit, in jedem Kontext, Die Komplexität ist sehr unterschiedlich, selbst wenn Sie nur eine Handvoll von Kontext und Entitäten haben. Dies bedeutet normalerweise, dass Sie viele Entities (einen in jedem Kontext) haben, selbst wenn alle von demselben Persistenzspeicher unterstützt werden (im Falle von ER-Speicher dieselben Table/s).

1

Es gibt keine eindeutige Definition der Komplexität, aber es gibt eine nützliche Beschreibung in Vaughn Vernon Buch (Implementing Domain Driven Design): Tabelle 1.1 Die DDD Scorecard.

Er beschreibt das Projekt mit verschiedenen Kriterien, zum Beispiel: ein komplexes Projekt wird sich oft ändern (neue Features und es wird kaum zu erwarten sein), Sie verstehen die Domäne nicht (oder es gibt eine Menge Mehrdeutigkeit, die Sie mit Business-Experten besprechen müssen), die Größe wie @jlvaquero sagte (Anzahl der Feature/Regeln/Reichhaltigkeit der Sprache ...).