【发布时间】:2014-12-16 18:09:16
【问题描述】:
在我的公司,我们有一个非常具体的定价策略:
- 我们目录中的每个
Product都有一个baseUsdPrice,例如产品 Foo 的基础美元价格为 9.99 美元。 - 这并不一定意味着您将支付 9.99 美元。我们会检查您所在国家/地区的价格例外情况 - 例如,GB Foo 成本为 8.99 美元
- 此外,您还可以选择要支付的货币 - 如果您使用 GB,您可以使用美元(提到 8.99 美元)或您的当地货币(在本例中为英镑)支付。
- 如果您选择使用当地货币支付,我们会根据固定价格矩阵计算出 8.99 美元兑换英镑的等值(例如,此处为 3.99 英镑)
- 这是你付出的代价。
我应该如何以 DDD 方式设计我的 Product 聚合根,使其干净、内聚、解耦且易于更改?
- 是否应该由域服务计算
paymentPrice并将其结果作为Product聚合的一部分?如果是这样,这意味着我的ProductRepository将拥有像product(productId, countryId, currency)这样的方法 - 我是否应该将所有计算放在域服务类
PaymentPriceCalculator中并使用像getPaymentPrice(Country, Currency)这样的访问者模式?如果我需要使用我的实体的paymentPrice来执行一些业务规则检查怎么办?
我正试图绕开它,但我想我想太多了,这很痛苦。 ;)
【问题讨论】:
-
一个想法是
Decorator模式用您的功能(方法)包装您的对象(用户),并使用Factory Pattern推出不同类型的对象(用户)。
标签: oop design-patterns domain-driven-design