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