Welche Probleme finden Sie bei dieser Sicht auf domänengesteuertes Design?

Question

Ich habe gerade eine lange (und unordentliche) blogpost über meine Sicht auf Domain-driven Design in der heutigen Zeit, mit Frameworks wie Frühling und Hibernate massiv verwendet.

Ich würde Sie bitten, irgendwelche Probleme mit meinen Ansichten zu der Frage zu erkennen - warum das nicht funktioniert, warum es nicht die Vorteile von DDD gibt, warum es im Allgemeinen keine gute Idee ist.

The blogpost is here (Ich glaube nicht, dass ich es auf SO kopieren muss - wenn Sie denken, dass ich sollte, sagen Sie mir).

Ich weiß, die Frage ist subjektiv, aber es zielt darauf ab, die vorherrschenden Meinungen zu sammeln.

(Ich bin Tagging Java, da die diskutierten Frameworks Java-Frameworks ist)

Answer 1

Ich habe gerade ein Jahr meines Lebens damit verbracht, eine Anwendung auseinander zu reißen, um ein anämisches Domänen-Anti-Pattern und dessen Missbrauch von Hibernate zu eliminieren.

Ich kann ohne Zweifel sagen, dass der Code, der als Ergebnis von DDD kommt, viel einfacher zu verstehen und zu refaktorieren ist. In unserem Fall hat die Beseitigung einer Unzahl von unnötigen Gettern, die Zunahme der Verkapselung, die Konzentration der Geschäftslogik und die daraus resultierende (dramatische) Vereinfachung der Service-Schichten, die mit DDD einhergehen, das System so viel einfacher zu warten gemacht dass ich jetzt glaube, dass wir es fertig stellen können, während es vorher für immer in die Länge zog. Wir haben die Anzahl der Zeilen dieser Anwendung um 50% reduziert, ohne jegliche Funktionalität zu entfernen.

Ich glaube auch, dass der gesamte Punkt eines ORM-Tools ist, so dass meine Geschäftslogik nicht mit Persistenz-Code aufgeräumt ist. Als wir ein anämisches Domänenmodell hatten, hatten wir für jede Domänenklasse ein DAO, jetzt haben wir eine kleine Handvoll DAOs als Einstiegspunkt für CRUD in den "großen" Domänenklassen, aber die anderen "kleinen" Domänenklassen werden von ihre Eltern ... nicht weil die Persistenzlogik im Elternteil ist sondern weil Hibernate transparent auf die Geschäftslogik reagiert und alles Just Work macht.

Kurz gesagt, ich kann diese SO Frage nicht beantworten, weil ich ausdrücklich mit Ihrem Beitrag 100% zustimme ... und ich lebe es jeden Tag.

Answer 2

Wir sind mit dem „anämisch Modell“ -Ansatz gehen, so dass wir die gleichen Modelle mit unterschiedlicher Business-Logik wiederverwenden können. Wir fügen jedoch Berechnungen und Hilfsmethoden in unsere Modelle ein, wenn sie für alle Fälle anwendbar sind. Aber wir injizieren unseren Modellen nichts und injizieren unsere Modelle nicht in IoC.

Answer 3

Persönlich bin ich nicht überzeugt, dass der Teil über das Einbringen von Repository-Objekten in die Domain-Objekte (dh die persistenten Entitäten) mit Spring und Hibernate notwendig ist. Hibernate stellt bereits persistente Sammlungen bereit, die lazy loading ausführen können, sodass Sie das Domänenmodell bereits so durchqueren können, dass die Datenzugriffsinfrastruktur von der Geschäftslogik getrennt ist. Ich sehe nicht, welchen Wert das Anhängen von Repositories an das Domänenmodell hinzufügt.

EDIT: Ups, postete dies vor dem Lesen des gesamten Artikels. Jetzt, da ich den gesamten Blogpost gelesen habe, denke ich, dass ich damit einverstanden bin. Ich mag den Teil, der empfiehlt, ohne DTOs zu arbeiten, wo immer es möglich ist.