Очевидно, что я ошибаюсь, говоря, что DDD схож с EAV / CR по полезности, но единственное различие, которое я вижу до сих пор, заключается в построении физических таблиц для каждой сущности с большим количеством объединений, а не с тремя таблицами и множеством объединений.
Это должно быть из-за моего отсутствия понимания DDD. Как вы физически сохраняете эти объекты в базе данных без значительных объединений и сложностей при импорте данных? Я знаю, что вы можете просто создавать объекты, которые поступают в ваш репозиторий, но сложно обучать таким инструментам, как Microsoft Sql Server Integration Сервер для использования ваших пользовательских объектов C # и фреймворка. Может быть, это должен быть мой вопрос, как вы используете вашу среду DDD ASP.NET C # со службами интеграции Microsoft SQL Server и службами отчетов? LOL.
В базе данных EAV / CR мы можем настроить одну таблицу Person с разными классами в зависимости от типа человека: поставщик, клиент, покупатель, представитель, компания, уборщик и т. Д. Три таблицы, несколько объединений, атрибуты всегда вставляйте строку с проверкой перед вставкой, так же, как ModelValidation в MVC, где объект принимает любое значение, но не сохраняется до тех пор, пока он не будет действительным.
В стандартной реляционной модели мы использовали для создания таблицы для каждого типа сущности, смешивая с избыточными типами данных, такими как City.
Используя Domain Driven Design, мы используем объекты для представления каждого типа сущности, вложенных объектов для каждого типа ValueObject и других вложенных объектов по мере необходимости. В моем понимании это приводит к таблице для каждого вида сущности и таблице для каждого вида набора информации (объекта значения). Со всеми этими таблицами я вижу много объединений. Мы также заканчиваем тем, что создали физическую таблицу для каждого нового типа контакта. Очевидно, что есть лучший способ, поэтому я должен ошибаться в том, как я сохраняю объекты в базе данных.
Мой продавец выглядит так:
public class Vendor {
public int vendorID {get; set;}
public Address vAddress {get; set;}
public Representative vRep {get;set;}
public Buyer vBuyer {get; set;}
}
Мой покупатель:
public class Buyer {
public int buyerID {get; set;}
public Address bAddress {get; set;}
public Email bEmail {get; set;}
public Phone bPhone {get; set;}
public Phone bFax (get; set;}
}
Действительно ли мы ссылаемся на такие вещи, как Vendor.vBuyer.bPhone.pAreaCode? Я бы подумал, что мы будем ссылаться и хранить Vendor.BuyerPhoneNumber и создавать объекты почти как псевдонимы следующих частей: Vendor.Address1, Vendor.Address2, Vendor.BuyerPhoneNumber ... и т. Д.