胖领域模型 => 低效？

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)

如果发票只需要打印客户名称，为什么我们要携带所有其他信息呢？使用仓储类型的方法似乎会构建这些复杂的领域对象，这些对象需要所有这些资源（CPU、内存、复杂的查询连接等），然后将其传输到客户端。

简单地向发票类添加一个customerName属性会打破抽象，并且似乎是一种可怕的做法。另一方面，像Customer这样的对象填充一半似乎是一个非常糟糕的想法，因为您可能会创建多个版本的同一对象（例如，一个具有Address但没有ShoppingHistory的对象，以及一个具有AccountingInfo但没有Address的对象等等）。我缺少什么或者我没有理解？

- MunkiPhD

Answer 1

好的对象关系映射器可以惰性加载关系，因此您将为发票检索客户，但忽略其会计和购物历史记录。如果您没有使用对象关系映射器，则可以自己编写。

通常，您无法在客户端内执行此操作，因为您已经跨越了事务边界（结束了数据库事务），因此由服务层确保已加载正确的数据。

测试正确的数据是否可用（且不会太多）通常最好在服务层的单元测试中进行。

- RichH

---

好的观点。我想我可能没有完全理解懒加载 >.< - MunkiPhD

Answer 2

你说“已经确定客户类必须实现AccountingInfo和ShoppingHistory”，因此系统执行的任务不仅仅是显示发票（否则怎么能“确定”客户需要这些其他功能呢？）。

所以，无论如何，您都需要一个客户表（用于这些其他功能）--当然，您的发票打印机需要从该表中获取客户数据（即使只是名称），与系统中其他功能使用的相同表格。

因此，“开销”纯粹是虚幻的--当您孤立地看待一个功能时，它似乎存在，但是当您将整个系统作为一个整体集成时，它根本不存在。

- Alex Martelli