Question

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

例如，假设我们有系统在屏幕上显示客户的发票。根据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属性添加到发票类中将会脱离抽象，看起来像是一种可怕的做法。第三方面，填写像Customer这样的对象似乎是一个非常糟糕的主意，因为你最终可能会创建同一个对象的多个版本（例如，一个有一个Address，但没有ShoppingHistory，一个有AccountingInfo但没有地址等等）。我错过了什么，或者不理解？

Answer 1

由于好的对象关系映射器可能会延迟加载关系，因此您将撤回客户的发票，但忽略其会计和购物历史记录。如果你没有使用对象关系映射器，你可以自己动手。

通常你不能在你的客户端内执行此操作，因为你已经越过了trasaction边界（结束了数据库trasaction），因此由服务层决定是否已经加载了正确的数据。

在服务层的单元测试中，通常可以测试正确的数据（而不是太多）。

Answer 2

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

所以你需要一个客户表（对于那些其他功能） - 当然你的发票打印机需要从那个表中获取客户数据（甚至只是名称），与其他功能所使用的相同。系统。

所以“开销”纯粹是虚幻的 - 当你单独看一个功能时它似乎存在，但当你把整个系统视为一个整体时它根本就不存在。

Fat Domain Models =＆gt;效率低下？

2 个答案: