Architecture 映射与服务层或业务逻辑位置

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

在我的持久性层中，我得到了三个类：Product、Payer和ProductManuallyPayment，如果产品是手动支付的，则这是Product和Payer之间的多对多类，指定每个付款人必须支付的百分比

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

---

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

DDD可能建议您采用一种思路，首先关注对象模型的设计，而不是ER/数据模型。我看到您已经思考了数据模型应该如何看待（多对多表等），但也许您应该考虑对象模型是如何首先查看的。然后，由于该对象模型反映了域（业务逻辑、业务行为），请考虑如何将该对象模型映射到数据库

例如，退回具有付款集合的产品可能更有意义。每个付款都有一个到付款人实体的链接。根据您的设计，付款人链接可能有您想要访问的付款人信息的副本，或者该链接知道如何使用必要的信息/值加载完整的付款人实体。 此外，每个付款人实例可能都有一个付款集合（甚至与上面的类类型相同？），这些付款集合链接回产品

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

我对DDD的想法还不太熟悉。在DDD这个词吓跑你之前，看看这个。这是一个轻阅读和免费下载。它可能会给你一直在寻找的宝石