You’d have a separate validator object for each of those entities.

If I call a method on an entity and inside the method I do some business rule checking, how can I pass the validation results (and messages) from the domain layer to the presentation layer!

Assume that a service method tries to execute 2 methods on 2 separate entities. Both entities could/should be validated (business rules like: allow adding another order, unless previous order is not fulfilled or so) and results from both entities should be passed to the user.

Throwing a custom exception when rules fail won’t help (cause we would loose – not execute – validations from the second entity)…

Any good practices/advices? Thanx.

You might want to consider using a domain event instead of an exception. I’ve written this up here:

http://www.udidahan.com/2009/06/14/domain-events-salvation/

But I have not attended your workshop yet! I am looking forward to the end to end solution in the workshop.

Great hearing from you.

The service layer receives a message/invocation indicating the wish of a customer rep to give a discount to an order, here’s the code of that object:

public void HaveCustomerRepGiveDiscount(Guid orderId, Guid customerRepId, double discount)
{
var rep = this.Session.Get<ICustomerServiceRepGivesDiscount>(customerRepId);
var order = this.Session.Get<Order>(orderId);

rep.GiveDiscount(order, discount);
}

Then, when the ORM is going to persist the changes, it can look for the validators.

Does that answer your question?

I will be attending your workshop in Austin December 09 so looking forward to the whole week.

I have a question about your latest comment about:
IValidator<Order, ICustomerServiceRepGivesDiscount>

What exactly is the process ICustomerServiceRepGivesDiscount? Is it something like a service operation to be validated like below or do you mean it in a different context?

class CustomerServices : ICustomerService {
void GiveDiscountToCustomer(ICustomerServiceRepGivesDiscount activity) { }
}

interface ICustomerServiceRepGivesDiscount {
Customer Customer { get; }
Discount Discount { get; }
}

CustomerServiceRepGivesDiscount : ICustomerServiceRepGivesDiscount {
// interface implementation and process specific behavior //
}

CustomerServiceRepGivesDiscountValidator : IValidator<Order, ICustomerServiceRepGivesDiscount> {

}

Thanks

Glad you liked them.

The processes in the system are really just representations of use cases:

IRegularUserChangesOwnAddress
IAdministratorCancelsBatch
ICustomerServiceRepGivesDiscount

Then, it’s not just about validating the given entity by itself, but in the given context. When going to give a discount to a customer for an order, our service layer would go look for:

IValidator<Order, ICustomerServiceRepGivesDiscount>

When designing your system around tasks rather than classic CRUD, these techniques become much more straight-forward since you don’t have to infer the process from a generic UPDATE call.

That kind of validation is usually done at the XSD / Service Layer level.

Just one small question to follow up, if the presentation model is doing simple validation (length/range) is that validation repeated in the associated domain model classes?

The kind of validations are those which are really business rules:

Regular customers can’t order more than $10K per month.
Orders can’t be accepted for discontinued products.
etc.

However, if you are using a presentation model – a different set of objects than those used in and around persistence, you can put real validation rules on them:

String lengths, value ranges, etc.

Those things which are process dependent or user dependent may be better handled by external validators.

Hope that helps.

What kind of validations will remain of the domain objects?

In a smart client scenario, let’s say that the view was given a domain object class and bound its controls to it. Of course the domain object will make sure the data that its given is valid. The validators I’m talking about here aren’t necessarily taking that away from the domain.

The “hard part” that I’m addressing here is matching these validation rules to specific processes – something the domain objects should know nothing about.

Does that answer your question?

Isn’t this going a bit against the domain model pattern as you are pulling out the validation logic from your domain classes thus leaving it to basically contain only data? A bit like the anemic domain model anti-pattern?

Carel