我有一个产品和一组付款人。付款人可以通过三种不同的方式为产品付款，但手动设置百分比，付款人收入或付款人各自持有的价值。如何支付产品由产品上的枚举决定。
在我的持久层中，我有三个类，Product、Payer 和 ProductManuallyPaid，如果产品是手动支付的，它是 Product 和 Payer 之间的多对多类，指定每个 Payer 必须支付的百分比。
我应该如何将其映射到视图？我想要一个新的多对多类（包括对付款人的引用、对产品的引用以及付款人应支付的确切金额）？
我想计算应该在服务层中完成，但是服务层应该返回一个 ViewModel/DTO 版本的产品/付款人，并附加一个新的多对多类，还是应该在之后处理？如果应该在之后处理，实体是否应该包含一个新的多对多类的列表，但在持久层中被忽略？
DDD 可能会建议您采用一种思路，首先关注对象模型的设计，而不是 ER/数据模型。我看到您已经考虑过数据模型的外观（使用多对多表等），但也许您应该首先考虑对象模型的外观。然后，当该对象模型反映领域（业务逻辑、业务行为）时，请考虑如何将该对象模型映射到数据库。
例如，返回包含 Payments 集合的 Product 可能更有意义。每个付款都有一个到付款人实体的链接。根据您的设计，付款人链接可能具有您想要访问的付款人信息的副本，或者该链接可能知道如何使用必要的信息/值加载完整的付款人实体。此外，每个 Payer 实例可能有一个 Payments 集合（甚至与上面的类类型相同？），它们链接回 Product。
与关系数据库相比，这种设计更好地利用了 OO 原则并更好地描述了域。此外，这些对象在服务和 UI 层中可能更容易处理，因为它们的原生对象结构已经在逻辑上为您提供了所需的东西。IE。一个产品有付款，有付款人等。
我对 DDD 自己的想法相当陌生。在 DDD 一词吓跑您之前，请看一下Evan 的书的摘要版本。这是一个轻松的阅读和免费下载。它可能只是给你你一直在寻找的宝石。