【问题标题】:Where to put validation of value object that require database lookup?在哪里放置需要数据库查找的值对象的验证?
【发布时间】:2016-03-17 05:41:27
【问题描述】:

我有一个带有一些属性的实体优惠券,其中之一是平台。 Platform 是一个具有单一属性的值对象:名称。比如网页平台有Coupon,Android应用平台也有Coupon。

在管理仪表板中,管理员可以为她正在创建的新优惠券指定平台。由于我们的业务正在增长,我决定将有效/支持的平台列表放入数据库的表中。因此,当我们推出新的 iPhone 应用程序时,我可以简单地向平台表添加新条目(我还没有时间为其创建仪表板,但将来可能,但现在直接添加到数据库已经足够简单了)。

我目前的实现如下:

CouponApplicationService {
  createCoupon(percentage, platformName) {
    platform = platformRepository.getByName(platform name)
    coupon = new Coupon(percentage,platform)
    couponRepository.save(coupon)
  }
}

但是,我感到很奇怪,我必须为 ValueObject 创建存储库。这样做真的可以吗?或者我错误地认为 Platform 是一个 ValueObject,它实际上是一个需要 ID 的实体?

谢谢

【问题讨论】:

    标签: validation domain-driven-design


    【解决方案1】:

    拥有值对象的存储库确实是一种代码异味,虽然不是很严重,只要您只执行上述查找操作即可。

    不过,我认为重新考虑您的域是有意义的。 也许有一个实体SupportedPlatforms 甚至更大的概念包含平台列表?如果是这种情况,这将是最好的解决方案。

    如果没有,请考虑定义应用程序配置对象。如果需要这种灵活性,系统通常会在数据库中拥有这些类型的配置对象。请注意,这通常不是一个商业概念。您仍然可以实现一个存储库来加载该配置。在您的情况下,它可能包含所有受支持平台的列表。

    如果您决定走这条路,如果应用配置对象很少更改,则可能有机会提高性能。您可以将其缓存在应用程序中。 (但无论如何,请确保不要以过早的优化告终)。

    【讨论】:

    • 既然您说值对象的存储库是代码异味,您是否会认为普通实体(不是 AR)的存储库也是代码异味?
    • 如果你使用一个实体作为存储库中的根对象,它会隐式变成一个聚合,你应该这样对待它。
    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 2011-08-25
    • 1970-01-01
    • 1970-01-01
    • 2016-05-08
    • 2013-07-12
    • 2012-05-27
    • 1970-01-01
    相关资源
    最近更新 更多