在我们的应用程序中,我们有一个需要根据业务规则和当前用户的上下文验证属性更新的场景。我正在尝试确定进行验证的最佳方法,因为我认为领域模型不应该知道当前用户的情况。我们的正常授权与域分开,与此场景不同。
这个验证应该在哪里发生,是否有更好的方法来处理它?领域模型应该了解用户吗?任何帮助或输入是感激的。
简单的例子:我们有一份订单,数量已得到批准。只有特定用户类型才能在特定方向更新数量。这是在域聚合中验证的正确方法吗?
public enum UserType
{
ViewUserType,
RequesterUserType,
SupplierUserType
}
public class Order
{
public int OrderId {get; private set}
public int RequestedQuantity {get; private set}
public int ApprovedQuantity {get; private set}
public void RequestQuantity(int quantity, UserType userType)
{
if (userType == UserType.RequesterUserType)
{
this.RequestedQuantity = quantity;
}
}
// Question: The direction that the approved quantity can change is a business rule
// but directly deals with the context of the user. Should the model know about the user
// or should this validation be pulled out to either the application service, a model extension,
// or maybe a specification?
public void ApproveQuantity(int quantity, UserType userType)
{
if (userType == UserType.RequesterUserType)
{
if (quantity <= this.ApprovedQuantity)
{
// Requester type user can only update if lowering the approved quantity
this.ApprovedQuantity = quantity;
}
}
else if(userType == UserType.SupplierUserType)
{
if (quantity >= this.ApprovedQuantity)
{
// Supplier type user can only update if increasing the approved quantity
this.ApprovedQuantity = quantity;
}
}
}
}
与其使用这种类似枚举的类型(UserType),为什么不将这些role演变成完全成熟的对象呢?您关心的是用户所扮演的角色,而不是特定的用户。这将用户确实是SUPPLIER或REQUESTER的身份验证和验证推到上面的层(实际上是调用代码,在本例中可能是某种应用程序服务)。下面是一个非常粗略的,第一次迭代的内容:
public class Order {
public void RequestQuantity(int quantity, UserType userType)
{
this.RequestedQuantity = quantity;
}
public void ApproveToLowerOrEqualQuantity(int quantity) {
if (quantity <= this.ApprovedQuantity)
{
// Requester type user can only update if lowering the approved quantity
this.ApprovedQuantity = quantity;
}
}
public void ApproveToHigherOrEqualtQuantity(int quantity) {
if (quantity >= this.ApprovedQuantity)
{
// Supplier type user can only update if increasing the approved quantity
this.ApprovedQuantity = quantity;
}
}
}
//Calling code
public class ApplicationServiceOfSomeSort {
public void RequestQuantity(UserId userId, OrderId orderId, int quantity) {
var requester = requesterRepository.FromUser(userId);
requester.MustBeAbleToRequestQuantity();
var order = orderRepository.GetById(orderId);
order.RequestQuantity(quantity);
}
public void ApproveQuantityAsRequester(UserId userId, OrderId orderId, int quantity) {
var requester = requesterRepository.FromUser(userId);
requester.MustBeAbleToApproveQuantity();
var order = orderRepository.GetById(orderId);
order.ApproveToLowerOrEqualQuantity(quantity);
}
public void ApproveQuantityAsSupplier(UserId userId, OrderId orderId, int quantity) {
var supplier = supplierRepository.FromUser(userId);
supplier.MustBeAbleToApproveQuantity();
var order = orderRepository.GetById(orderId);
order.ApproveToHigherOrEqualQuantity(quantity);
}
}
当然,围绕这个API仍然有很多"不好的味道",但这是一个开始。
这是受到Yves的回答和您的回复的启发。
我个人的信条是把隐含的东西变得显式,因为我喜欢应用这个原则后的代码:
public interface IProvideCurrentIdentityRoles
{
bool CanRequestQuantity()
bool CanApproveQuantity();
bool CanOverruleQuantityOnSubmittedOrder();
bool CanIncreaseQuantityOnFinalOrder();
bool CanDecreaseQuantityOnFinalOrder();
}
public class Order
{
public int OrderId {get; private set}
public int RequestedQuantity {get; private set}
public int ApprovedQuantity {get; private set}
public void RequestQuantity(int quantity, IProvideCurrentIdentityRoles requester)
{
Guard.That(requester.CanRequestQuantity());
this.RequestedQuantity = quantity;
}
public void ApproveQuantity(int quantity, IProvideCurrentIdentityRoles approver)
{
if (quantity == this.RequestedQuantity)
{
Guard.That(approver.CanApproveQuantity());
}
else
{
if (orderType == OrderType.Submitted)
{
Guard.That(approver.CanOverruleQuantityOnSubmittedOrder());
}
else if (orderType == OrderType.Final)
{
if (quantity > this.ApprovedQuantity)
{
Guard.That(approver.CanIncreaseQuantityOnFinalOrder());
}
else
{
Guard.That(approver.CanDecreaseQuantityOnFinalOrder());
}
}
}
this.ApprovedQuantity = quantity;
}
}