Wie konvertiere ich im domänengesteuerten Design eine Datenbanktabelle mit einem Primärschlüssel in ein Wertobjekt?

Nehmen wir an, es gibt ein Datenbankschema, das wie folgt definiert ist:

Person.mail_address_key ----- Address.address_key
Person.billing_address_key ----- Address.address_key

A Personhat eine Postanschrift und eine Rechnungsadresse. Als Denormalisierungstechnik erstellen wir eine separate AddressTabelle. Meistens haben das mail_address_keyund das billing_address_keyeines einzelnen Personden gleichen Wert (dh der Schlüssel für die Postanschrift und die Rechnungsadresse ist der gleiche).

In meiner Datenbank der Addresseine Identität (die Adresse Taste). Aber in meinem Domain - Modell , ich sehe keinen zwingenden Grund für die Addresseine Entität sein, ich möchte es ein Wertobjekt sein.

1. Ist dies in DDD eine Option? Oder sind Wertobjekte normalerweise eine Gruppe von Spalten (im Gegensatz zu einer Tabelle)? Ich spiele hier sozusagen den Anwalt des Teufels, weil ich nicht denke, dass die Datenbank die Struktur des Domänenmodells bestimmen sollte, sondern nur sicherstellen soll.
2. Wenn ja, wo / wann / wie verliert die Adresse ihre Datenbankidentität, damit sie als Wertobjekt in der Domänenschicht verwendet werden kann? Oder soll ich die Datenbankkennung im Wertobjekt behalten?
3. Was ist der Prozess, wenn das Modell in der Datenbank beibehalten werden muss? Soll ich einen Prozess durchlaufen: a) Eine Adresse anhand dieser Felder finden, b) Wenn sie nicht vorhanden ist, eine neue erstellen c) Wenn dies der Fall ist, die Felder aktualisieren?

Ist dies in DDD eine Option? Oder sind Wertobjekte normalerweise eine Gruppe von Spalten (im Gegensatz zu einer Tabelle)? Ich spiele hier sozusagen den Anwalt des Teufels, weil ich nicht denke, dass die Datenbank die Struktur des Domänenmodells bestimmen sollte, sondern nur sicherstellen soll.

Die Datenbank sollte die Domänenmodellstruktur nicht vorgeben, damit Sie diesbezüglich Recht haben. Wertobjekte können abhängig von der Art der Daten, die das Wertobjekt tragen soll, entweder als Spalte oder als Tabelle in der Datenbank gespeichert werden.

Wenn ja, wo / wann / wie verliert die Adresse ihre Datenbankidentität, damit sie als Wertobjekt in der Domänenschicht verwendet werden kann? Oder soll ich die Datenbankkennung im Wertobjekt behalten?

Ihr Domain-Code sollte nicht mit Eigenschaften durchsetzt sein, die für andere Belange wie Persistenz bestimmt sind, da diese vollständig persistenzunabhängig sein sollten. Sie sollten sich wirklich auf Ihre aggregierte Wurzel konzentrieren. Sie müssen eine Möglichkeit haben, Ihren Aggregatstamm zu identifizieren, wenn Sie ihn wieder in der Datenbank speichern. Zu diesem Zeitpunkt müssen Sie lediglich den Personentabellendatensatz überprüfen (ich gehe davon aus, dass Person Ihr Aggregatstamm ist) und prüfen, ob dies der Fall ist Ein Wert im Feld MailingAddressID oder BillingAddressID. An diesem Punkt können Sie entscheiden, ob Sie neue Adressen erstellen und die Links so ändern möchten, dass sie auf die neuen Adressen verweisen, oder ob Sie die bereits verknüpften Adressen überschreiben.

Was ist der Prozess, wenn das Modell in der Datenbank beibehalten werden muss? Soll ich einen Prozess durchlaufen: a) Eine Adresse anhand dieser Felder finden, b) Wenn sie nicht vorhanden ist, eine neue erstellen c) Wenn dies der Fall ist, die Felder aktualisieren?

Wie ich in der obigen Antwort etwas erklärt habe, sollten Sie Ihren Objektgraphen basierend auf Ihrer aggregierten Wurzel hydratisieren und deshydrieren. Wenn Ihr Repository Ihren Aggregatstamm aus der Datenbank abruft, werden daher auch alle erforderlichen Entitäten und Wertobjekte unter Ihrem Aggregatstamm hydratisiert, die Ihrem Aggregatstamm in der Datenbank zugeordnet sind. Das Gleiche gilt, wenn Sie das aggregierte Stammverzeichnis wieder in der Datenbank speichern. Ihr Repository sollte in der Lage sein, Ihr gesamtes Objektdiagramm unter dem aggregierten Stamm zu verarbeiten.

DDD erzwingt überhaupt kein DB-Schema. Das Wertobjekt kann als Gruppe von Spalten, DB-Entität (Ihre dritte Lösung) oder einfach in denormalisierter Form implementiert werden, wenn Sie beispielsweise eine dokumentorientierte Datenbank verwenden können. Es hängt von verschiedenen Umständen ab, welche Option die beste ist.

Beachten Sie, dass DB nur ein Tool zum Beibehalten Ihres Domänenstatus ist. Es sollte keine Entwurfsentscheidung erzwingen. Wenn Sie aus irgendeinem Grund die Identität für die Darstellung Ihres Wertobjekts in der Datenbank verwenden müssen, tun Sie dies, ohne diese Implementierungsdetails in die Domäne selbst zu übertragen. Erstellen Sie einen Wrapper / erweitern Sie Domänenklassen / was auch immer Ihr Framework zulässt, und fügen Sie die ID in einer vollständig separaten Infrastrukturklasse hinzu, damit die Anwendung / das Framework den Status beibehalten kann.

Ich sehe in diesem Fall keine besonderen Anforderungen von DDD. Sie können Post- und Rechnungsadressen als Eigenschaften einer Person modellieren und sie dennoch in einer separaten Tabelle speichern, zum Beispiel:

Person
+ MailingAddress : Address
+ BillingAddress : Address

oder

Person
+ MailingAddressID
+ MailingAddress : Address
+ BillingAddressID
+ BillingAddress : Address