Custom Field Design mit C # und RavenDB

Ich stehe vor einer wichtigen Designfrage im Zusammenhang mit dem Anfügen von benutzerdefinierten Feldern an Entitäten in meinem System. Die Entitäten werden in C # dargestellt und in RavenDB beibehalten. Wir folgen in etwa den Mietern von Domain Driven Design, und unsere Entitäten sind aggregierte Wurzeln.

[Hinweis: Ich möchte jede Debatte über die Angemessenheit eines generischen Features wie benutzerdefinierte Felder in einem DDD-Ansatz vermeiden. Nehmen wir an, wir haben einen rechtmäßigen Benutzer, der willkürliche Daten an unsere Entitäten anhängen und anzeigen muss. Außerdem habe ich meine Beispiele generisch zur Veranschaulichung der Design-Herausforderungen gemacht. :)]

Meine Frage bezieht sich darauf, wie die Felddefinitionen und Feldwert-Instanzen am besten dargestellt werden können.

Stellen Sie sich eine Domäne vor, in der wir die aggregierten Wurzeln von Buch und Autor haben. Wir möchten, dass Benutzer beliebige Datenattribute an Instanzen von Büchern und Autoren anhängen können. So könnten wir ein benutzerdefiniertes Feld mit einer Klasse wie dieser definieren:

Eine CustomFieldDefinition (CFD), die an Buch angehängt ist, könnte folgende Werte haben:

• ID: "BookCustomField \ 1"
• Name: "FooCode"
• Geben Sie Folgendes ein: Text
• Beschreibung: "Foo Corp's spezielle Kennung."
• Geben Sie Folgendes ein: Text
• Optionen: null

Die erste Frage, die mir bevorsteht, ist, was in jeder Instanz eines Buches gespeichert werden soll. Die Auswahlmöglichkeiten reichen von ...

das untere Ende:

speichert nur die CFD-ID und den Instanzwert

bis

das obere Ende:

speichert den gesamten CFD zusammen mit dem Wert

Das "niedrige Ende" ist schlecht, weil ich ein Buch nicht anzeigen kann, ohne den CFD, der in einem anderen Dokument ist, einzuziehen. Auch wenn ich den CFD in irgendeiner Weise ändere, habe ich die Bedeutung von Werten in historischen Dokumenten geändert.

Das "High-End" ist schlecht, weil es viele Duplikate geben würde. Der CFD könnte für ausgewählte CFDs sehr schwer sein, da die Definition alle auswählbaren Optionen enthält.

Die erste Frage ist ... Wie viel sollte im Dokument für jedes Buch gespeichert werden? Gerade genug, um das Buch anzuzeigen (und ich müsste zurück zum CFD gehen, um das Buch anzuzeigen Optionen und Beschreibung, wenn ich dem Benutzer erlauben soll, den CF-Wert zu bearbeiten)?

Die zweite Frage lautet ... Soll ich die gesamte Sammlung von CFDs für einen Entitätstyp in einem Dokument speichern oder jedes CFD in einem eigenen Dokument behalten?

Jeder CFD als Dokument hält die Dinge für jeden CFD einfach (besonders wenn ich anfange, Dinge wie Definitionen zu deaktivieren), aber dann brauche ich eine Möglichkeit, Buch CFDs von Autoren CFDs zu trennen. Dies zwingt mich auch, 1 Dokument für jede an die Entität angehängte CF zu laden, wann immer ich die Entität bearbeiten möchte.

Alle CFDs für einen bestimmten Typ in einem Dokument erlauben mir, nur ein Dokument zu laden, aber dann lade ich auch alle deaktivierten Definitionen.

Dritte Frage ... Gibt es einen besseren Weg, dies alles zu implementieren?

Vierte Frage ... Gibt es irgendwelche Muster- oder Open-Source-Lösungen, damit ich dieses Rad nicht neu erfinden muss?