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