【问题标题】:Domain model property to DTO域模型属性到 DTO
【发布时间】:2018-08-05 05:25:25
【问题描述】:

使用 DDD,如果我的域模型中有这样的东西:

public class OrderLineItem {
    public decimal UnitPrice { get; set; }
    public int Quantity { get; set; }
    public decimal LineTotal { get { return UnitPrice * Quantity; } }
}

dto 可以将 LineTotal 的属性设为public decimal LineTotal { get; set; },这很好。

假设我现在创建了一个作为 SPA 的 UI。如果我想在将带有数量的行项目添加到订单时显示行总计,是否需要在我的 dto/ViewModel/客户端重新创建计算,或者我可以将域模型中的计算移动到服务(?) 并从我的 SPA 中调用它?这似乎更合乎逻辑,但我不确定如何/在哪里编码。如果有人能指出一个真正有帮助的例子。

【问题讨论】:

  • 为什么要使用 DTO?域模型应该用于命令端。为什么不尝试在添加行时计算行总数然后存储总数?然后你可以用任何你喜欢的方式阅读它。我想说的是,您可以有两种模型,一种用于命令端(域模型),另一种用于读取端,即 CQRS。
  • 不太清楚你的意思。您是说要向域和“UI”模型添加相同的计算?

标签: c# asp.net-mvc domain-driven-design single-page-application


【解决方案1】:

当您尝试执行某些业务逻辑时,会使用域模型。例如,当添加新的 OrderLineItem 时,您可能会检查是否满足某些业务要求,例如所有 OrderLineItem 的总和不能大于 N,或者 OrderLineItem Quantity 必须为 min N。

此外,您可以存储计算的 LineTotal。没有必要一次又一次地计算它。您不希望您的客户在将商品放入购物篮后看到不同的 LineTotal。

当获取相同的 OrderLineItem 以在 UI 上显示它时,无需遍历所有业务规则,因为它们已经被检查过。 因此,您可以使用一个单独的模型来直接映射到您的表(或服务模型等)。

我建议阅读更多关于 CQRS(命令查询责任分离)以及它如何与 DDD 相匹配的内容。

重读您的问题后,我发现我没有完整回答您的问题。 在我看来,您至少有两条路径,这两条路径都包括在某些时候使用域模型。

您可以通过在后端调用一些代码来完全在前端添加 OrderLineItem 并计算 Total。我们可以将那段代码称为域服务。在添加了所有 OrderLineItem 并且您希望保留它们之后,您可以使用检查业务规则的域模型来添加它们。由于 UI 要求,您可能不得不复制一些业务逻辑。这是不可避免的。

第二种方法是第一种方法的变体,在添加 OrderLineItem 后立即使用域模型。这样,使用我在前几段中描述的方法计算并返回 Total。所有业务规则也会立即检查。

【讨论】:

  • 说的很有道理,谢谢你的解释!
猜你喜欢
  • 2013-12-03
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2011-01-05
  • 1970-01-01
相关资源
最近更新 更多