Дизайн пользовательского поля с помощью C# и RavenDB

Я столкнулся с ключевым вопросом дизайна, связанным с тем, как прикрепить настраиваемые поля к объектам в моей системе. Сущности представлены в C# и сохраняются в RavenDB. Мы примерно следуем арендаторам Domain Driven Design, и наши сущности являются совокупными корнями.

[Примечание: я хотел бы избежать каких-либо дебатов по поводу уместности общей функции, такой как настраиваемые поля, в подходе DDD. Предположим, у нас есть законный пользователь, которому нужно прикрепить и отобразить произвольные данные к нашим объектам. Кроме того, я сделал свои примеры общими для иллюстрации проблем дизайна. :)]

Мой вопрос касается того, как лучше всего разместить определения полей и экземпляры значений полей.

Представьте себе домен, в котором у нас есть совокупные корни Книги и Автора. Мы хотим, чтобы пользователи могли прикреплять произвольные атрибуты данных к экземплярам книг и авторов. Итак, мы могли бы определить настраиваемое поле с помощью такого класса:

public enum CustomFieldType
{
    Text,
    Numeric,
    DateTime,
    SingleSelect,
    MultiSelect
}

public class CustomFieldDefinition
{
    public string Id { get; set; }
    public string Name { get; set; }
    public string Description { get; set; }
    public CustomFieldType Type { get; set; }
    public Collection<string> Options { get; set; } 
}

CustomFieldDefinition (CFD), прикрепленный к Book, может иметь такие значения, как:

• Идентификатор: BookCustomField\1
• Имя: ФуКод
• Тип: текст
• Описание: специальный идентификатор Foo Corp.
• Тип: текст
• Параметры: null

Первый вопрос, с которым я сталкиваюсь, заключается в том, что хранить в каждом экземпляре книги. Выбор варьируется от...

нижний предел:

хранить только идентификатор CFD и значение экземпляра

to

высокий конец:

сохранить весь CFD вместе со значением

Нижний конец плохой, потому что я не могу отобразить книгу, не вытащив CFD, который находится в другом документе. Кроме того, если я каким-либо образом изменю CFD, я изменю значение значений в исторических документах.

Высокий конец плохой, потому что будет много дублирования. CFD может быть довольно тяжелым для CFD списка выбора, потому что определение содержит все доступные для выбора параметры.

Первый вопрос: Сколько должно храниться в документе для каждой Книги? Достаточно, чтобы отобразить Книгу (и мне пришлось бы вернуться к CFD, чтобы отобразить параметры и описание если я позволю пользователю редактировать значение CF)?

Второй вопрос: Должен ли я хранить всю коллекцию CFD для одного типа объекта в одном документе или хранить каждый CFD в отдельном документе?

Каждый CFD как документ упрощает работу с каждым CFD (особенно когда я начинаю делать такие вещи, как деактивация определений), но затем мне нужен способ отделить CFD книги от CFD автора. Это также заставляет меня загружать 1 документ для каждого CF, прикрепленного к объекту, всякий раз, когда я хочу редактировать объект.

Все CFD для данного типа в одном документе позволяют мне загрузить только один документ, но затем я также загружаю все деактивированные определения.

Третий вопрос... Есть ли лучший способ реализовать это в целом?

Четвертый вопрос... Есть ли какие-нибудь образцы или решения с открытым исходным кодом, чтобы мне не пришлось заново изобретать это колесо?