Performance Fat域模型=>；效率低下？

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

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

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)

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

简单地将customerName属性添加到invoice类将脱离抽象，这似乎是一种可怕的做法。在第三方面，一半填充一个对象（如客户）似乎是一个非常糟糕的主意，因为您可能最终创建同一对象的多个版本（例如，一个有地址但没有购物历史记录，另一个有AccountingInfo但没有地址，等等）。我遗漏了什么，或者不理解什么？

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

因此，您需要一个客户表（用于其他功能）——当然，您的发票打印机需要从该表中获取客户数据（甚至只是名称），该表与系统中其他功能使用的表相同

---

因此，“开销”完全是虚幻的——当你孤立地看一个功能时，它似乎存在，但当你将整个系统视为一个集成的整体时，它根本不存在。

由于良好的对象关系映射程序可以延迟加载关系，因此你会撤回客户以获取发票，但忽略他们的会计和购物记录。如果不使用项目关系映射器，您可以自己滚动

通常情况下，您无法在客户机中执行此操作，因为您已经跨越了传输边界（结束了数据库传输），因此应由您的服务层来确保加载了正确的数据

---

在服务层的单元测试中，测试可用的正确数据（而且数据不太多）通常是一件好事。

好的一点。我想我一定没有完全理解惰性加载>。