Kartierung vs.Serviceschicht oder Geschäftslogikposition

Question

Ich habe ein Produkt und eine Sammlung von Zahlern.Die Zahler können das Produkt auf drei verschiedene Arten bezahlen, entweder aber indem sie den Prozentsatz manuell festlegen, nach dem Einkommen des Zahlers oder nach dem Wert der jeweiligen Bestände des Zahlers. Wie das Produkt bezahlt wird, wird durch eine Aufzählung auf dem Produkt bestimmt.

In meiner Persistenzschicht habe ich drei Klassen: „Product“, „Payer“ und „ProductManuallyPaid“. Dabei handelt es sich um eine m:n-Klasse zwischen Produkt und Payer, wenn das Produkt manuell bezahlt wird, wobei der Prozentsatz angegeben wird, den jeder Payer zahlen muss.

Wie soll ich das der Ansicht zuordnen?Ich hätte gerne eine neue Many-to-Many-Klasse (die aus einem Verweis auf den Zahler, einem Verweis auf das Produkt und dem genauen Betrag, den der Zahler zahlen soll, bestehen würde)?

Ich schätze, die Berechnung sollte in der Service-Schicht erfolgen, aber sollte die Service-Schicht eine ViewModel/DTO-Version des Produkts/Zahlers mit einer neuen Viele-zu-Viele-Klasse zurückgeben, oder sollte dies später erledigt werden?Wenn es später behandelt werden soll, sollte die Entität dann eine Liste dieser neuen Many-to-many-Klasse enthalten, aber in der Persistenzschicht ignoriert werden?

Answer 1

DDD schlägt möglicherweise vor, dass Sie eine Denkweise übernehmen sollten, die sich in erster Linie auf das Design des Objektmodells und nicht auf das ER/Datenmodell konzentriert.Ich sehe, Sie haben darüber nachgedacht, wie das Datenmodell aussehen soll (mit der Viele-zu-Viele-Tabelle usw.), aber vielleicht sollten Sie zuerst darüber nachdenken, wie das Objektmodell aussehen könnte.Da dieses Objektmodell dann die Domäne (Geschäftslogik, Geschäftsverhalten) widerspiegelt, überlegen Sie, wie Sie dieses Objektmodell der Datenbank zuordnen könnten.

Beispielsweise kann es sinnvoller sein, ein Produkt zurückzugeben, für das Zahlungen eingezogen wurden.Und jede Zahlung hat einen Link zur Zahlereinheit.Abhängig von Ihrem Design enthält dieser Zahler-Link möglicherweise Kopien der Zahler-Informationen, auf die Sie zugreifen möchten, oder dieser Link weiß, wie die gesamte Zahler-Entität mit den erforderlichen Informationen/Werten geladen wird.Darüber hinaus verfügt jede Zahlerinstanz möglicherweise über eine Sammlung von Zahlungen (sogar derselbe Klassentyp wie oben?), die auf das Produkt zurückführen.

Dieses Design nutzt OO-Prinzipale besser und beschreibt die Domäne besser als dies bei einer relationalen Datenbank der Fall wäre.Darüber hinaus sind diese Objekte in den Ebenen „Dienste“ und „UI“ möglicherweise einfacher zu handhaben, da ihre native Objektstruktur Ihnen bereits logisch die Dinge bereitstellt, die Sie benötigen.dh.Ein Produkt hat die Zahlungen, die den Zahler haben usw.

Ich selbst bin relativ neu im DDD-Denken.Und bevor der Begriff DDD Sie abschreckt, werfen Sie einen Blick darauf zusammengefasste Version von Evans Buch.Es ist leicht zu lesen und kann kostenlos heruntergeladen werden.Es könnte Ihnen genau die Juwelen bescheren, nach denen Sie gesucht haben.