Модели Fat Domain => Неэффективно?

Question

Глядя на DDD, мы абстрагируем базу данных от различных моделей, над которыми работаем, и рассматриваем ее как хранилище, в котором живут наши модели. Затем мы добавляем уровни данных и уровни обслуживания / бизнеса. Мой вопрос заключается в том, создаем ли мы при этом неэффективность передачи данных путем построения жирных моделей?

Например, скажем, у нас есть система, которая отображает счет для покупателя на экране. Думая об этом с точки зрения ООП, мы, вероятно, в итоге получили бы объект, который выглядит примерно так:

class Invoice {
    Customer _customer;
    OrderItems _orderitems;
    ShippingInfo _shippingInfo;
}

class Customer {
    string name;
    int customerID;
    Address customerAddress;
    AccountingInfo accountingInfo;
    ShoppingHistory customerHistory;
}
    (for the sake of the question/argument, 
    let's say it was determined that the customer class had to 
    implement AccountingInfo and ShoppingHistory)

Если в счете исключительно необходимо напечатать имя клиента, зачем нам брать с собой весь другой багаж? При использовании подхода с использованием репозитория создается впечатление, что мы будем создавать эти сложные доменные объекты, которые требуют всех этих ресурсов (ЦП, память, сложные объединения запросов и т. Д.), И затем передавать их по каналам клиенту.

Простое добавление свойства customerName к классу счетов-фактур оторвется от абстракций и станет ужасной практикой. С третьей стороны, наполовину заполнение объекта, такого как Customer, кажется очень плохой идеей, так как вы можете создать несколько версий одного и того же объекта (например, тот, у которого есть Address, но нет ShoppingHistory, и тот, у которого есть AccountingInfo, но нет Адрес и т. Д. И т. Д.). Что я упускаю или не понимаю?

Answer 1

Так как хорошие объектно-реляционные картографы могут лениво загружать отношения, вы, следовательно, отзовете клиента для своего счета, но проигнорируете его учет и историю покупок. Вы можете свернуть свой собственный, если вы не используете объектно-реляционный маппер.

Зачастую вы не можете сделать это в своем клиенте, поскольку вы пересекли границу транзакции (завершили транзакцию базы данных), и поэтому ваш уровень обслуживания должен гарантировать, что нужные данные были загружены.

Тестирование нужных данных доступно (и не слишком много), часто полезно проводить в модульных тестах на сервисном уровне.

Answer 2

Вы говорите, что «было определено, что класс клиента должен был реализовать AccountingInfo и ShoppingHistory», поэтому четкое отображение счета-фактуры НЕ является единственной задачей, которую выполняет система (как иначе было «определено», что клиенты нуждаются в этих других функциях, иначе ? -.)

Таким образом, вам все равно нужна таблица клиентов (для других функций) - и, конечно, ваш принтер счетов-фактур должен получать данные о клиентах (даже просто имя) из этой таблицы, той же, которая используется другими функциями в система.

Таким образом, «накладные расходы» являются чисто иллюзорными - кажется, что они существуют, когда вы смотрите на одну функциональность изолированно, но вообще не существуют, когда вы смотрите на всю систему как на единое целое.