我有一个域聚合，称之为“订单”，其中包含一个订单行列表。订单跟踪订单行上的金额总和。客户有一个正在运行的“信用”余额，他们可以从中订购，这是通过汇总他们的数据库交易历史来计算的。一旦他们用完“池”中的所有钱，他们就不能再订购任何产品了。
因此，每次将一行添加到订单中时，我都需要检查池中还剩下多少，以及订单是否将它们推过它。池中的金额不断变化，因为其他相关客户不断使用它。
问题是，从 DDD 的角度考虑，我如何获得这个数量，因为我不想用 DataContext 问题污染我的域层（在此处使用 L2S）。由于我不能只从域中查询到数据库，我将如何获取该数据以便验证业务规则？
这是使用领域事件的实例吗？
【问题讨论】：
标签： domain-driven-design aggregates
您的订单聚合应完全封装。因此，它需要能够确定添加项目是否有效，即是否超出客户信用。有多种方法可以做到这一点，但它们都依赖于 Order 存储库返回一个特定的聚合，该聚合知道如何执行此特定操作。例如，这可能与您用于满足订单的订单聚合不同。
在这种情况下，您必须识别并在代码中捕获您期望订单履行特定角色的事实，即添加额外订单项的角色。为此，您可以为此角色创建一个接口，并为该角色创建一个内部支持的相应聚合。
然后，您的服务层可以向您的订单存储库请求满足此显式角色接口的订单，因此存储库有足够的信息来说明您需要什么来构建可以满足该要求的东西。
例如：
public interface IOrder
{
IList<LineItem> LineItems { get; }
// ... other core order "stuff"
}
public interface IAddItemsToOrder: IOrder
{
void AddItem( LineItem item );
}
public interface IOrderRepository
{
T Get<T>( int orderId ) where T: IOrder;
}
现在，您的服务代码如下所示：
public class CartService
{
public void AddItemToOrder( int orderId, LineItem item )
{
var order = orderRepository.Get<IAddItemsToOrder>( orderId );
order.AddItem( item );
}
}
接下来，实现IAddItemsToOrder 的 Order 类需要一个客户实体，以便它可以检查信用余额。因此，您只需通过定义特定接口来级联相同的技术。订单存储库可以调用客户存储库以返回履行该角色的客户实体并将其添加到订单聚合中。
因此，您将拥有一个基本的ICustomer 接口，然后以ICustomerCreditBalance 接口的形式从它派生出一个显式角色。 ICustomerCreditBalance 既充当客户存储库的标记接口，告诉它您需要客户做什么，所以它可以创建适当的客户实体，并且它具有支持特定角色的方法和/或属性。比如：
public interface ICustomer
{
string Name { get; }
// core customer stuff
}
public interface ICustomerCreditBalance: ICustomer
{
public decimal CreditBalance { get; }
}
public interface ICustomerRepository
{
T Get<T>( int customerId ) where T: ICustomer;
}
显式角色接口为存储库提供他们需要的关键信息，以正确决定从数据库中获取哪些数据，以及是急切地还是延迟地获取数据。
请注意，在这种情况下，我已将CreditBalance 属性放在ICustomerCreditBalance 接口上。但是，它也可以在基础ICustomer 接口上，ICustomerCreditBalance 然后变成一个空的“标记”接口，让存储库知道您将要查询信用余额。这一切都是为了让存储库知道您希望它返回的实体的角色。
正如您在问题中提到的，将这一切结合在一起的最后一部分是域事件。如果超出客户的信用余额，订单可以引发故障域事件，以通知服务层订单无效。另一方面，如果客户有足够的信用，它可以更新客户对象上的余额或引发域事件以通知系统的其余部分需要减少余额。
我没有将域事件代码添加到 CartService 类，因为这个答案已经很长了！如果您想了解有关如何执行此操作的更多信息，我建议您针对该特定问题发布另一个问题，我将在那里进行扩展；-)
【讨论】：
在这种情况下，我使用事件或委托来减轻责任。也许最简单的方法就是使用一些代码来展示。
您的订单类将有一个Predicate<T>，用于确定客户的信用额度是否足够大以处理订单。
public class Order
{
public Predicate<decimal> CanAddOrderLine;
// more Order class stuff here...
public void AddOrderLine(OrderLine orderLine)
{
if (CanAddOrderLine(orderLine.Amount))
{
OrderLines.Add(orderLine);
Console.WriteLine("Added {0}", orderLine.Amount);
}
else
{
Console.WriteLine(
"Cannot add order. Customer credit line too small.");
}
}
}
您可能会有一个 CustomerService 类或类似的东西来提取可用的信用额度。在添加任何订单行之前设置 CanAddOrderLine 谓词。这将在每次添加行时检查客户的信用。
// App code.
var customerService = new CustomerService();
var customer = new Customer();
var order = new Order();
order.CanAddOrderLine =
amount => customerService.GetAvailableCredit(customer) >= amount;
order.AddOrderLine(new OrderLine { Amount = 5m });
customerService.DecrementCredit(5m);
毫无疑问，您的实际情况会比这更复杂。您可能还想查看Func<T> 代表。委托或事件对于在下订单后减少信用金额或在客户超出订单中的信用额度时触发某些功能可能很有用。
祝你好运！
【讨论】：
除了获取“池”值的问题（我将使用 OrderRepository 上的方法查询该值）之外，您是否考虑过锁定影响这个问题？
如果“池”不断变化，是否有可能在您的规则通过之后，但在您将更改提交到数据库之前，其他人的事务会悄悄进入？
Eric Evans 在他的书（“聚合”）的第 6 章中提到了这个问题。
【讨论】：