Hier unser Geschäftsfall,
Die Anwendung bietet ein sofortiges Angebot für das verwendete iPhone und ermöglicht es dem Verkäufer, es sofort zu verkaufen. Auf der anderen Seite gibt es Käufer, die bereit sind, es sofort zu kaufen oder auf die Angebote bieten. Potenzielle Einzelhandelsverkäufer können Website besuchen und sofortiges Angebot erhalten [iQuote123] basierend auf Jahr, Modell, Zustand, Zubehör-Eingaben.
Das System erstellt jedes Mal, wenn jemand den Prozess verwendet, eine neue Angebots-ID. Wenn der Verkäufer sich entschließt, das Angebot anzunehmen, wird es sofort mit weiteren Informationen über Seriennummer, Fotos usw. akzeptiert. Das System generiert eine eindeutige Transaktions-ID [iTransaction123].
In seltenen Fällen kann ein Käufer das iPhone aufgrund von Problemen nicht anzeigen oder ablehnen. Wir können einen anderen Käufer für den Verkäufer finden.
Ich möchte eine Meinung darüber einholen, ob wir eine neue Transaktions-ID generieren sollten, wenn der Käufer sich ändert oder der Verkäufer die Bedingungen später ändert, nachdem er das Angebot angenommen hat.
Wenn wir die gleiche Transaktions-ID behalten, bleibt es den Verkäufern einfach, sich nur eine Referenz zu merken, die Sinn macht, da sie für dasselbe iPhone, aber nur unterschiedliche Käufer für Backend-Supportmitarbeiter, Kommunikationsthread für diese einzigartige Transaktion mit Kommunikation erzeugt alte und neue Käufer. Ich denke, der beste Weg ist, ein separates Objekt für die Käufertransaktion [iBuyerTransaction123] zu erstellen und es mit der Transaktion des Verkäufers abzubilden, so dass es mehrere Käufertransaktionsobjekte für denselben Verkäufer erstellt, falls der erste Käufer es nicht ausführen kann.
Ich bin auf der Suche nach dem besten Weg, Domain-Identitäten zu behandeln, mit Richtlinien darüber, wann ich Identitäten erstellen und wann ich sie wiederverwenden kann.
Ich möchte eine Meinung darüber einholen, ob wir eine neue Transaktions-ID generieren sollten, wenn der Käufer sich ändert oder der Verkäufer die Bedingungen später ändert, nachdem er das Angebot angenommen hat.
Häufigste Antwort in - melden Sie sich bei Ihren Domain-Experten an.
Ausgehend von Ihrer Beschreibung würde ich erwarten, dass in Ihrem Modell eine Entität vorhanden ist, die Sie noch nicht entdeckt haben, die den vorgeschlagenen Austausch zwischen einem Käufer und einem Verkäufer darstellt.
Speculating (Ich kenne Ihre Domain nicht), Sie haben wirklich zwei verschiedene Dinge hier. Zuerst haben Sie einen Stapel von Kaufanfragen und Verkaufsanfragen, die Sie abstimmen möchten. Dann, nachdem Sie eine Übereinstimmung gefunden haben, gibt es einen Austausch Prozess , der durch die tatsächlichen Verhandlungen zwischen den beiden Parteien funktioniert. Auf dem glücklichen Weg sind beide Seiten zufrieden, und alles erreicht das Ende des Lebens. Wenn eine der Parteien durch den Austausch unzufrieden ist, endet der Austausch, aber die beiden Parteien gehen wieder in den passenden Stapel.
Sie benötigen eine Entität, um den Status dieses Prozesses zu verfolgen.
Die Ansicht des Verkäufers würde auf ihren einen Verweis geklickt werden, und dieser Schlüssel würde verwendet werden, um den aktuellen Austausch nachzuschlagen (wenn einer gerade läuft), und zuvor geschlossene Austauschvorgänge (falls vorhanden).
Dies ist tatsächlich ein allgemeines Muster bei der Modellierung - wenn Sie zwei Entitäten haben, die jeweils eine unabhängige Lebensdauer haben, wird die Interaktion zwischen diesen beiden Entitäten oft in einer dritten Entität verfolgt, die ihren eigenen Lebenszyklus hat.
Tags und Links transactions domain-driven-design identity