DDD - 将 ConfigurationService 注入实体答案

【问题标题】：DDD - Injecting a ConfigurationService into an EntityDDD - 将 ConfigurationService 注入实体
【发布时间】：2013-07-25 07:17:57
【问题描述】：

在我的域模型中，我有一个名为“Inventory”的实体。要在库存中进行特定移动，我需要访问业务级别配置以进行检查。

我在库存实体中有以下方法

public class Inventory
{
  // Some codes, properties and arguments are omitted for brevity.
  public int InventoryId { get; set; }
  public virtual Product Product { get; set; }
  public virtual IList<InventoryTransaction> Transactions { get; set; }
  public virtual IList<Stock> Stocks {get; set; }
  // ........

  public void purchase(double qty, decimal cost) { //....... }
  public double QuantitiesOnHand() { //..... }
  public decimal CostOfItemsOnHand() { //....... }

  // This method require to access certain configuration in order to 
  // process the sale of item.
  public decimal Sell(double qty, decimal cost) { //..... }
}

要处理销售，我需要访问某些配置。注入配置接口以在该实体内处理销售是否是一种好习惯。会不会破坏DDD的纯度？还是应该只将这个“Sell()”方法移动到域服务层？

编辑：

public virtual IList<Stock> Stocks {get; set; } 已添加到上述类定义中，该类定义包含特定库存项目的库存。

【问题讨论】：

为什么不把配置值传给sell方法呢？
DomainService 为简单起见，或在造成损害时对其进行重构。
@DavinTryon，你是对的。但我需要通过大约 3 到 4 个设置。我也怀疑将来它可能会增加。请说出你的建议。
是的，传递给方法是可以接受的，注入实体构造函数将违反其他用例的 SRP 并使构造复杂化。
如果方法实现的行为需要，您可以将任何类型的域服务传递给实体上的方法。如果您将其转移到域服务或应用服务，您所做的就是将业务逻辑从实体中移开。

标签： c# .net domain-driven-design

【解决方案1】：

销售/购买操作看起来不属于该实体。我的意思是，这些操作可能（并且可能是）比仅仅减少/增加数量要多得多。此外，他们的职责可能跨越多个实体。

这些方法非常适合某种域服务。例如：

public class InventoryTradeService
{
  public void purchase(Inventory inventory, double quantity)
  public void sell(Inventory inventory, double quantity)
}

关于你的“ConfigurationService”，如果它是你所说的“业务级配置”，它应该是域模型的一部分。因此，没有理由注入它 - 只需访问它。如果它不是模型的一部分，请考虑合并它。

【讨论】：

其实在我的设计中，Inventory 是一个单一的实体，负责处理单个产品的库存。所以单件商品的购买/销售将列在实体的 IList Transactions 列表和 IList Stocks 列表中。在那种情况下，我认为我们不需要为此提供单独的服务。建议。
我有点担心 Inventory 作为聚合根，包含 IList<InventoryTransaction 和 IList<Stock> 可能会变得太大。知道您计划存储多少交易和库存吗？
@BlueBird你能描述一下你的业务级配置，里面是什么东西？
@JefClaes, IList 可以在事务发生时尽可能地增长到最大值。但是 IList 将受到限制，因为它描述了可以转售的实际库存。请有任何建议..
@gseric，我有一些配置，例如“允许负余额”、“成本计算方法”等。