在我的公司,我们有一个非常具体的定价策略：

>我们目录中的每个产品都有一个baseUsdPrice,例如产品Foo的基础美元价格为9.99 $.
>这并不意味着你将支付9.99美元.我们检查您所在的国家/地区是否存在价格异常 – 例如GB Foo的费用为8.99美元
>您还可以选择您想要支付的货币 – 如果您使用的是GB,您可以支付美元(提到8.99美元)或当地货币(在这种情况下为英镑).
>如果您选择以当地货币付款,我们根据固定价格矩阵计算相当于8.99美元到英镑的汇率(例如,此处为3.99英镑)
>这是你支付的价格.

我应该如何以DDD方式设计我的产品聚合根,以保持清洁,内聚,分离和易于更改？

> paymentPrice是否应由域服务计算,其结果是否作为Product aggregate的一部分？如果是这样意味着我的ProductRepository将具有类似product(productId,countryId,currency)的方法
>我应该将所有计算放在域服务类PaymentPriceCalculator中并使用访问者模式,如getPaymentPrice(Country,Currency)吗？如果我需要使用来自我的实体的paymentPrice来执行某些业务规则检查,该怎么办？

我试图绕过它,我想我正在过度思考它而且很痛. 😉

最佳答案 我倾向于你的第二个选择,即拥有PaymentPriceCalculator.这样,如果您决定更改算法或使用多种算法,您将能够使用不同的计算器.

>我不会把它放在产品汇总中,因为价格因国家/地区而异.它还会使您的Product类更复杂.从域名的角度来看,即使它们是在不同的国家购买,也不是2个相同的产品“相等”吗？
>访客模式并不适合这里.

我可能还有第二项服务,将$转换成所需的任何货币.这应该是单独的服务,因为您的域似乎使用美元用于所有内容,直到最后用户需要实际支付的东西.通过这种方式,您还可以添加适用的税/增值税等,与按国家/地区计算价格例外的逻辑分开.