Fat域模型=>低效？

Question

看看DDD，我们将数据库抽象到各种模型中，并将其视为模型所在的存储库。然后添加数据层和服务/业务层。我的问题是，在这样做的过程中，我们是否通过建立fat模型来造成数据传输的低效？

例如，假设我们有在屏幕上显示客户发票的系统。从面向对象( OOP )的角度来看，我们可能最终会得到一个看起来有点像这样的对象：

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)

如果发票只需要打印客户的名字，我们为什么要随身携带其他行李呢？使用存储库类型的方法似乎是构建这些需要所有这些资源(CPU、内存、复杂查询联接等)的复杂域对象，然后通过管道将其传输到客户端。

将customerName属性简单地添加到发票类中将脱离抽象，这似乎是一种可怕的实践。第三，像客户一样半填充一个对象似乎是一个非常糟糕的主意，因为您最终可能会创建同一个对象的多个版本(例如，一个有地址但没有ShoppingHistory，另一个有AccountingInfo但没有地址等等)。我错过了什么，还是不理解？

Answer 1

由于好的对象关系映射器可以延迟加载关系，因此您将撤回客户的发票，但忽略它们的记帐和购物历史。如果不使用对象关系映射器，您可以使用自己的映射器。

通常情况下，您不能在客户端内这样做，因为您已经越过了trasaction边界(结束了数据库的事务处理)，所以应该由您的服务层来确保正确的数据已经加载。

在服务层的单元测试中，测试正确的数据(而不是太多的数据)通常是好的。

Answer 2

您说“已确定客户类必须实现AccountingInfo和ShoppingHistory"，因此清楚地显示发票并不是系统执行的唯一任务(否则如何”确定“客户需要其他功能？-)。

所以你无论如何都需要一个客户表(对于其他功能) --当然，你的发票打印机需要从那个表中获取客户数据(甚至只是名称)，这是系统中其他功能使用的相同的数据。

所以“开销”纯粹是虚幻的--当你孤立地看待一个功能时，它似乎是存在的，但是当你把整个系统看作一个完整的整体时，它根本不存在。