1

我有一个产品和一组付款人。付款人可以通过三种不同的方式为产品付款,但手动设置百分比,付款人收入或付款人各自持有的价值。如何支付产品由产品上的枚举决定。

在我的持久层中,我有三个类,Product、Payer 和 ProductManuallyPaid,如果产品是手动支付的,它是 Product 和 Payer 之间的多对多类,指定每个 Payer 必须支付的百分比。

我应该如何将其映射到视图?我想要一个新的多对多类(包括对付款人的引用、对产品的引用以及付款人应支付的确切金额)?

我想计算应该在服务层中完成,但是服务层应该返回一个 ViewModel/DTO 版本的产品/付款人,并附加一个新的多对多类,还是应该在之后处理?如果应该在之后处理,实体是否应该包含一个新的多对多类的列表,但在持久层中被忽略?

4

1 回答 1

3

DDD 可能会建议您采用一种思路,首先关注对象模型的设计,而不是 ER/数据模型。我看到您已经考虑过数据模型的外观(使用多对多表等),但也许您应该首先考虑对象模型的外观。然后,当该对象模型反映领域(业务逻辑、业务行为)时,请考虑如何将该对象模型映射到数据库。

例如,返回包含 Payments 集合的 Product 可能更有意义。每个付款都有一个到付款人实体的链接。根据您的设计,付款人链接可能具有您想要访问的付款人信息的副本,或者该链接可能知道如何使用必要的信息/值加载完整的付款人实体。此外,每个 Payer 实例可能有一个 Payments 集合(甚至与上面的类类型相同?),它们链接回 Product。

与关系数据库相比,这种设计更好地利用了 OO 原则并更好地描述了域。此外,这些对象在服务和 UI 层中可能更容易处理,因为它们的原生对象结构已经在逻辑上为您提供了所需的东西。IE。一个产品有付款,有付款人等。

我对 DDD 自己的想法相当陌生。在 DDD 一词吓跑您之前,请看一下Evan 的书的摘要版本。这是一个轻松的阅读和免费下载。它可能只是给你你一直在寻找的宝石。

于 2009-12-12T07:01:28.860 回答