Ist das wirklich DDD?

Question

Ich bin zu 80% sicher, dass ich diese Frage nicht stellen sollte, weil sie als negativ empfunden werden könnte und ich respektlos gegenüber niemandem, besonders dem Autor dieses Buches, bin. Ich habe mehrere Beiträge gesehen, die dieses book und seinen Begleiter project empfehlen. Ich habe das Buch nicht gelesen, aber ich habe heute ein paar Stunden damit verbracht, das Projekt zu studieren. Und obwohl es sehr vollständig aussieht, habe ich eine sehr harte Zeit damit, wie viel Details verstreut sind. Ich kämpfe in meinen eigenen Entwürfen mit dem, wie viel ich ändern muss, wenn sich ein Wesen ändert, und dieses Projekt macht mich als Lösung nicht sehr bequem.

Zum Beispiel gibt es ein Employee-Objekt, das von einer Person erbt. Die Person hat einen Konstruktor mit Vorname, Nachname usw. und damit auch Employee. Privat für Mitarbeiter sind Mitglieder für den Vornamen, den Nachnamen sowie öffentliche Eigenschaften für denselben Benutzer.

Es gibt eine EmployeeFactory, die sowohl die Employee und Personal-Eigenschaften als auch die SQL-Spaltennamen kennt (um Werte von einem Lesegerät zu ziehen).

Es gibt ein EmployeeRepository mit nicht implementiertem PersistNewItem und PersistUpdatedItem-Methoden, von denen ich vermute, dass, falls implementiert, SQL für INSERT- und UPDATE-Anweisungen erstellen würde, wie ich es in CompanyRepository sehe. Diese schreiben die Eigenschaften in Strings, um das SQL zu erstellen.

Es gibt einen 'Datenvertrag' PersonContract mit denselben privaten Mitgliedern und öffentlichen Eigenschaften wie Person und einem EmployeeContract, der von PersonContract wie Employee does Person erbt, wobei öffentliche Eigenschaften die Entitäten spiegeln.

Es ist eine statische ‚Converter‘ Klasse mit statischen Methoden, die Entitäten Verträge abzubilden, einschließlich

EmployeeContract ToEmployeeContract(Employee employee) 

die kopiert die Felder von einem zum anderen, einschließlich der Person Felder aus. Es kann eine Begleitmethode geben, die in die andere Richtung geht - nicht sicher.

Ich denke, es gibt auch Komponententests.

Insgesamt zähle ich 5-10 Klassen, Methoden und Konstruktoren mit detaillierten Kenntnissen über Entitätseigenschaften. Vielleicht sind sie automatisch generiert - nicht sicher. Wenn ich der Person eine "Anrede" oder eine andere Eigenschaft hinzufügen müsste, müsste ich alle diese Klassen/Methoden anpassen? Ich bin sicher, ich würde etwas vergessen.

Nochmals, ich meine keine Respektlosigkeit und dies scheint ein sehr gründliches, detailliertes Beispiel für das Buch zu sein. Ist das DDD getan?

Answer 1

DDD s neu genug (zumindest in gewisser Hinsicht), dass es ein wenig zu früh ist, um genau zu sagen "wie es gemacht wird". Die Idee gibt es zwar schon lange, aber wir haben uns keinen coolen Namen dafür ausgedacht.

In jedem Fall ist die kurze Antwort (IMAO) "ja, aber ...." Die Idee von einem domänengetriebenen Design ist es, die Domäne sehr explizit zu modellieren. Sie betrachten ein Domänenmodell, dh ein objektorientiertes Modell, das die Problemdomäne in der Sprache der Problemdomäne beschreibt. Die Idee ist, dass ein Domänenmodell, da es die "reale Welt" modelliert, relativ unempfindlich gegenüber Veränderungen ist und auch dazu neigt, Veränderungen zu lokalisieren. Wenn also beispielsweise Ihre Vorstellung davon, was ein Mitarbeiter ist, sich ändert, vielleicht durch Hinzufügen einer Postanschrift sowie einer physischen Adresse, dann wären diese Änderungen relativ lokalisiert.

Sobald Sie dieses Modell haben, haben Sie, was ich behaupte, sind architektonische Entscheidungen noch zu treffen. Beispielsweise haben Sie die nicht implementierte Persistenzschicht, die in der Tat einfach eine SQL-Konstruktion sein kann.Es könnte auch eine Hibernate-Schicht sein oder Python-Beize verwenden oder sogar etwas Wildes wie eine verteilte Google AppEngine-Tabellenstruktur sein.

Die Sache ist, diese Entscheidungen werden getrennt getroffen, und mit anderen Gründen, als die Domain-Modellierung Entscheidungen.

Etwas, mit dem ich zu einem guten Ergebnis experimentiert habe, ist, das Domänenmodell in Python zu erstellen und dann einen Simulator damit zu bauen, anstatt das endgültige System zu implementieren. Dies ist etwas, mit dem der Kunde experimentieren kann, und ermöglicht Ihnen möglicherweise auch, quantitative Schätzungen über die Dinge zu machen, die die endgültige Implementierung bestimmen muss.

Answer 2

Domain Driven Design ist wirklich einfach. Es sagt: Lassen Sie Ihre Modellklassen die reale Welt widerspiegeln. Also, wenn Sie Mitarbeiter haben, haben Sie eine Mitarbeiterklasse und stellen Sie sicher, dass sie die Eigenschaften enthält, die ihr die "Angestellten" geben.

Die Frage, die Sie stellen, ist nicht über DDD, sondern eher über die Klassenarchitektur im Allgemeinen. Ich denke, Sie haben Recht, einige der Entscheidungen über die Klassen in Frage zu stellen, aber es ist nicht speziell mit DDD verwandt. Es bezieht sich mehr auf OOP-Programmiermuster im Allgemeinen.

Answer 3

Was unterscheidet DDD von "bloßen" Modell-getriebenen Design ist der Begriff "Aggregat-Wurzeln", dh eine Anwendung ist nur zulässig, Referenzen auf aggregierte Wurzeln zu halten, und im Allgemeinen werden Sie nur haben ein Repository für die gesamte Root-Klasse, nicht die Klassen, die das aggregierte Root verwendet

Dies räumt den Code erheblich auf; die Alternative sind Repositories für jede Modellklasse, die "nur" ein geschichtetes Design ist, nicht DDD