Advanced error handling in DDD/CQRS

[Alexandre Potvin Latreille]

I've read a lot of blog posts about error handling in DDD/CQRS and none every really explained (or perhaps I did not understand) most of the questions I had so here we go:

 

The context

 

Let's say we take an example where the client issues a ChangeBillingInformation command that allows to modify the billing address, the customer name as it appears on the card as well as other related information such as the card number. There are various reasons this command might be rejected. For example, the card number might be invalid or the billing address might not match the one registered with the bank for this card.

 

The problem

 

While the UI could potentially validate the format of all fields by itself, it certainly couldn't know if the card number exists without invoking a remote service. Since I do not want to replicate business logic in the UI and limit roundtrips to the server as much as possible (web app), I believe these rules should be handled during the command handling process.

 

However, I find it quite challenging to come up with an efficient and elegant solution to provide the client with all the necessary information so that the user knows all the reasons that made his request fail.

 

In order to correctly perform this task, I believe the client must be provided a collection that states (for every error) what are the command properties involved, the error code and a default localized message. The propertie names would be useful for error placement in the UI while an error code would allow the UI generating a custom localized error message, however the service itself should probably return some default localized messages to avoid imposing this burden on the client.

 

The angry client

 

If you ever tried to change your billing information from your PS4 to access the Play Station Network (PSN), you know how frustrating it is when you recieve a message that is way too general such as "Invalid credit card information". I agree that's probably for security purposes, but you get the point. The client will get angry if you can't tell him exactly what has to be fixed. 

 

The solution?

 

Does anyone have an idea how to implement such mechanism with CQRS? Is there already a pattern that I am not aware of or perhaps am I misunderstanding some concepts which leads to increasing complexity? So far I really do not see any other way than having the command handler itself (or using a validator object)  validate all these details before manipulating the aggregate, but then what about rules that were perhaps already enforced by value objects or aggregate methods? Woudln't they have to be replicated? Is that acceptable?

 

Thanks!

[Kijana Woodard]

- Ask the business how important this is. [we all assume "VERY" when the answer could be "very"].

- Do what you can to validate the command to minimize the chance of failure downstream.

- Discuss/define/document what [manual?] processes will be employed in the case of failure.

- Measure how often you get into the failure state

- Ask the business how important this is.......

--
You received this message because you are subscribed to the Google Groups "DDD/CQRS" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dddcqrs+u...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Alexandre Potvin Latreille]

If I hear you correctly, your answer seems to be that it's quite important not to overengineer and I agree with you, however what if the error reporting is a key aspect to the business efficiency and customer's happiness? Precise and pertinent error reports can often help users just like good exception messages will facilitate debugging and I believe the users are in their right to consider the error reporting a central pillar of their systems. It's a concern present in virtually every application and unfortunately I haven't been able to find/craft a satisfying solution just yet. I am very interested to learn about how expert DDD/CQRS practitioners would deal with such problem.

[davidz]

Here is one way that I'm doing:

I have CommandValidators that validate commands before they are sent, my client/app doesn't directly send commands but instead I have a CommandSender concept that will find a CommandValidator for a Command and perform validation, if successful the CommandSender will send the command. If any errors are encountered these are reported back to the client via a list of command properties and associated error message for erroneous properties. In my MVC extension of the CommandSender I map Command properties to Model properties, so that the errors can be displayed to the user.

Just to be safe the validators in my case are shared with CommandExecutor (concept that will call handlers) so CommandExecutor (upon receiving a Command) will perform validation again using the same validators. My handlers do not do any validation.

////////////////////////////////////////////////////////////

Sample code:

////////////////////////////////////////////////////////////

// Config the map

var commandToModelMap = new CommandToModelMap<CreateFooCommand, CreateModel>();

commandToModelMap.For(c => c.FooDescription).Map(m => m.Description);

commandToModelMap.For(c => c.FooName).Map(m => m.Name);

var commandSender = IoCContainer.Resolve<IMVCCommandSender>();

// validate and if ok send command. Else CommandSender will add Model state errors and map to model properties then return false.

var command = new CreateFooCommand(fooId, model.Name, model.Description);

if (commandSender.ValidateAndSend(command, this, commandToModelMap))

{

  return RedirectToAction("Index", "Foo");

}

return View(model);

////////////////////////////////////////////////////////////

Sample Validation

///////////////////////////////////////////////////////////

public class CreateFooCommandValidator : ICommandValidator<CreateFooCommand>

{

  public ICollection<CommandValidation<CreateFooCommand>> Validate(CreateFooCommand command)

  {

    var results = new List<CommandValidation<CreateFooCommand>>();

    CheckEventSourceIdValid(command, ref results);

      

    return results;

  }

  private static void CheckEventSourceIdValid(CreateFooCommand command, ref List<CommandValidation<CreateFooCommand>> results)

  {

    var result = new CommandValidation<CreateFooCommand>();

    if (command.FooId == Guid.Empty)

    {

      results.Add(result.AddError(Localization.ErrorMessages.FooIdEmpty, c => c.FooId));

    }

  }

}

Disclaimer :) This is just my way of doing things, you may not need to Validate twice like I do or might not use MVC however the same concept can apply, you have a command it has properties you have some input form it has properties, you validate command and map property errors.

[davidz]

Sorry forgot to mention that validators are part of my domain and therefore I let them tryCreate valueobjects, and my readmodel repositories contracts are also part of domain so my validators can use these too.

[Fabian Schmied]

While I think it's always important to check how important a feature really is, I also think it's not very helpful to (on this list) automatically assume that it's not ;)

Let's assume it is very or VERY important to differentiate error conditions. In that case, error conditions become an important part of the business domain, and also of the ubiquitous language. That is, each error condition to be reported to the user has to be modeled and becomes part of the domain's/command's contract.

Personally, I'd try to create different exception types named according to the ubiquitous language that are part of the command's contract. Where only details make a difference, I might use a common exception and something like a Reason enum, maybe passing some additional context with the exception. The UI would then create it's own localized message from the specific exception type and, if available, Reason and context data. For unexpected exceptions, I'd display a "system error" with exception details as "technical information".

Best regards,
Fabian

Von meinem Windows Phone gesendet

---

Von: Alexandre Potvin Latreille
Gesendet: 15.01.2014 03:25
An: ddd...@googlegroups.com
Betreff: Re: [DDD/CQRS] Advanced error handling in DDD/CQRS

If I hear you correctly, your answer seems to be that it's quite important not to overengineer and I agree with you, however what if the error reporting is a key aspect to the business efficiency and customer's happiness? Precise and pertinent error reports can often help users just like good exception messages will facilitate debugging and I believe the users are in their right to consider the error reporting a central pillar of their systems. It's a concern present in virtually every application and unfortunately I haven't been able to find/craft a satisfying solution just yet. I am very interested to learn about how expert DDD/CQRS practitioners would deal with such problem.

 

On Tuesday, January 14, 2014 7:21:38 PM UTC-5, Kijana Woodard wrote:

- Ask the business how important this is. [we all assume "VERY" when the answer could be "very"].

- Do what you can to validate the command to minimize the chance of failure downstream.

- Discuss/define/document what [manual?] processes will be employed in the case of failure.

- Measure how often you get into the failure state

- Ask the business how important this is.......

On Tue, Jan 14, 2014 at 4:47 PM, Alexandre Potvin Latreille <alexandre.pot...@gmail.com> wrote:

I've read a lot of blog posts about error handling in DDD/CQRS and none every really explained (or perhaps I did not understand) most of the questions I had so here we go:

 

The context

 

Let's say we take an example where the client issues a ChangeBillingInformation command that allows to modify the billing address, the customer name as it appears on the card as well as other related information such as the card number. There are various reasons this command might be rejected. For example, the card number might be invalid or the billing address might not match the one registered with the bank for this card.

 

The problem

 

While the UI could potentially validate the format of all fields by itself, it certainly couldn't know if the card number exists without invoking a remote service. Since I do not want to replicate business logic in the UI and limit roundtrips to the server as much as possible (web app), I believe these rules should be handled during the command handling process.

 

However, I find it quite challenging to come up with an efficient and elegant solution to provide the client with all the necessary information so that the user knows all the reasons that made his request fail.

 

In order to correctly perform this task, I believe the client must be provided a collection that states (for every error) what are the command properties involved, the error code and a default localized message. The propertie names would be useful for error placement in the UI while an error code would allow the UI generating a custom localized error message, however the service itself should probably return some default localized messages to avoid imposing this burden on the client.

 

The angry client

 

If you ever tried to change your billing information from your PS4 to access the Play Station Network (PSN), you know how frustrating it is when you recieve a message that is way too general such as "Invalid credit card information". I agree that's probably for security purposes, but you get the point. The client will get angry if you can't tell him exactly what has to be fixed. 

 

The solution?

 

Does anyone have an idea how to implement such mechanism with CQRS? Is there already a pattern that I am not aware of or perhaps am I misunderstanding some concepts which leads to increasing complexity? So far I really do not see any other way than having the command handler itself (or using a validator object)  validate all these details before manipulating the aggregate, but then what about rules that were perhaps already enforced by value objects or aggregate methods? Woudln't they have to be replicated? Is that acceptable?

 

Thanks!

--

You received this message because you are subscribed to the Google Groups "DDD/CQRS" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dddcqrs+u...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Alexey Raga]

To me it is totally fine to perform validation of a command in the command handler. You may extract it into a separate "validation layer", but since there is one command handler per command I don't see a big deal here.

Even if your commands are "one way", you can still validate the command synchronously before accepting it. If the command is invalid you just throw an (meaningful and contextful) exception and let your client deal with it (presentation and localization typically is client's concern).

From my point of view when you accept the command (start executing it) you implicitly say "this command is valid enough to bother my domain".

I also don't see any difference in providing your client with error codes when using CQRS or not. Isn't it the same if you just use ASP.NET MVC + EF with CRUD? 

Could you elaborate more on the problem specifics?

Cheers,

Alexey.

On Wednesday, January 15, 2014 9:47:30 AM UTC+11, Alexandre Potvin Latreille wrote:

[Kijana Woodard]

Right. There's nothing particular to cars about validating inputs.

I suppose the op may mean handling eventual consistent errors assuming you're handling command off a queue? In that case, establish av back channel to communicate these errors to the users, assuming the user can correct the problem. Signalr, email, etc.

--

[@yreynhout]

To say it in the words of The Karate Kid: "Batch In, Batch Out" => track intent more finegrained at the client, record all intents (commands), send as a batch, report back as a batch (teasing apart any errors in there). Personally, I wouldn't even bother, but it's your prerogative to deal with it this way. Alternatively, you might want to make the client more intelligent about the validation concerns if it's THAT important, doing verifications as you type, or as a background process (and don't you go DRY on me here ;-)), or whatever makes your boat fly.

Or ... you could just use "The Magic Bullet" and be done.

[Kijana Woodard]

Ooooh. What's The Magic Bullet?

I agree with @yreynhout. I can't imagine that _every_ interaction needs this much attention. The cost of a manual fix might be so small that even the cost of the discussion to confirm that will dwarf the expenditure.

There is an argument to made for DRY as in only validate at the client [you are confirming that posts are from valid clients, right?]. For the "safety validation" my thought is, if you're not confident about one block of code, you should be less confident about two.

btw...just noticed that android auto-corrected cqrs to cars in my last post. :-]

--

[Alexandre Potvin Latreille]

The difference is that I am trying to find a solution which won’t violates DDD principles and work well with tactical modeling tools such as value objects. The client could always get so smart that it could validate everything by itself, but it seems like an hacky fix for a domain that has the ability to enforce rules but the inability to report errors properly. I see very well how value objects could be used in the domain to enforce addresses format validity, customer's name validity, credit card number format and how specifications or another external validator mechanism could be used to validate that the billing information as a whole is valid for the given card, but not what would be the most efficient way of collection error details and report them.

 

Let’s take the following handler example (pseudo-code):

 

function handle(cmd) {

    var customer = _customerRepository.getById(cmd.customerId);

 

    customer.changeBillingInformation(new BillingInformation(

        new VisaCreditCard(cmd.creditCardNumber, ...),

        new Address(...),

         ...

    ));

 

    ...

} 

 

There's no issue enforcing rules with such code. The handler doesn't even know that validation takes place and that's great, but the handler also can't return a detailed error report. At its best it can throw a meaningful exception, but that doesn't help with multiple rule violations.

 

So far the only solution I've seen was to duplicate all the rules already carefully enforced by value objects using a validation framework of some kind which would be used to validate commands from handlers, but then I'm asking myself if that wouldn't consist of a validate everywhere anti-pattern if I keep validating within the value objects as well? Not to say that wouldn’t be very DRY, especially when we take in consideration that some of these rules might have to be replicated on the remote client, and that there might be multiple client implementations.

 

Perhaps it would be easier without enforcing the always-valid entity paradigm? This way we could simply construct a BillingInformation object, declare rules that a framework can consume and have the command handler use the framework to validate the object? It seems to work for collecting simple data-oriented errors, but not so much for business rules enforced during processes such as (fictive rule) “a client cannot change his billing information more than twice a day”. I understand that these rules should be mutually exclusive, but it would be nice if the errors could still be reported the same way.

 

Another approach I thought of would be to pass an OperationResult object around through every method that might communicate an error. Errors would be added to the OperationResult instance as the process gets executed. Then the handler would have to check whether there were issues or not before persisting changes using the repository. We also need a mechanism to halt the process completely in case it doesn’t make sense to continue. In this case perhaps a method like recordErrorAndThrow could be added on the OperationResult object.

 

The code could look like:

 

function handle(cmd, result) {

    var customer = _customerRepository.getById(cmd.customerId);

 

    customer.changeBillingInformation(new BillingInformation(

        new VisaCreditCard(cmd.creditCardNumber, result),

        new Address(…, result),

        result

    ), result);

 

   if (result.ok()) _customerRepository.save(customer);

 

}

 

 

What about such an approach? Obviously that wouldn’t help with rules validation on the client, but would help to have good error reporting from domain operations.

[Kijana Woodard]

- Why can't the domain class throw new VaildationException { Errors: { "..." : "...", "..." : "...", ......... } } ?

- In my mind, domain models are not bound by the limits of a single class. Js code enforcing command validity on the client is still the same "domain model" to me. I don't know how others feel about this.

- Passing around the result object looks cumbersome.

--

[@yreynhout]

- Improving the UX is a client concern. Reporting back more than one validation error at a time is an optimization to cater for an improved UX, IMO. Remember, in applying CQRS, the task based UI is an essential part, striving to make every command it emits a 'done deal'.

- Backing up a bit, when I hear people saying "duplication on the client and the server", I generally assume they are in a situation where they are doing all the work, both client and server. At that point it's pretty natural for them to start bitching about duplication because their back-end SOLID, <more-acronyms-here>, DRY mind kicks in and tries to apply that to the client+server code. Suppose I had to deal with this yuppie client dev, that's good at html, js, css, photoshop, wireframing, etc ... that couldn't care less about all this DDD shit? Well, he'd ask similar questions as the back-end dev, but he'd be thinking about improving the UX, not the attack vector/security, and certainly not about keeping things DRY between client and server. So the point becomes moot rather quickly in that situation, doesn't it? You may disagree, but I've been in both situations and learned to stop being so (pardon my language) anal about it.

- Structural validation of a command can be done. I find it very useful. Depending on the client stack or the stack emitting the commands it can be shipped closer to them, so they send "less" crap. Obviously, value objects are still the final frontier.

- The pattern of passing a collector (collecting parameter) around could work if you're dead set on doing this. But you have to admit, it kinda pollutes the whole design. Alternatively, you could try catch collect your way out of this situation.

- Honestly - and mind you I don't mind discussing this - I think by the time I'm done writing this, the client dev already "duplicated" the rules for UX needs in the UI. Saving money by DRYing things up can be pretty relative at times.

- Address validity - you're so funny (there's no such thing).

[João Bragança]

I think the key to understanding this problem is that there are many
kinds of validation. The OP is mixing them, e.g. is this a valid
credit card number (LUN 10) vs can I proceed if this credit card and
address don't line up with what the bank says? The latter is domain
knowledge, the former is not.

I can say that as a user, I would want to get feedback on the former
types of problems immediately. Also, as a developer I would not want
to make a remote call on what is obviously an invalid credit card
number.

The latter types of validation do not belong in the command handler.
The former may, as a cross cutting concern that goes around your
handler.

> --
> You received this message because you are subscribed to the Google Groups
> "DDD/CQRS" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to dddcqrs+u...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.

--
Sent from my regular computer
http://twitter.com/thefringeninja
http://www.thefringeninja.com/

[Alexandre Potvin Latreille]

 @Kijana "Why can't the domain class throw new VaildationException { Errors: { "..." : "...", "..." : "...", ......... } } ?"

 

I do not see how you would construct that "Errors" map from domain objects without some kind of error collector object being passed around?

 

@yreynhout I must agree that when another tier builds the client, you are far less concerned about this. However when you are in an organization that massively develop softwares internally for it's own use, you start thinking a lot about code reuse and integration. The try-catch collect approach might be interesting, I will think about it. A collector object approach would be far more interesting if it could simply be injected or if we could have control over the code execution context to push a new object on the scope chain that could be used from any code executing in that context. We would then only have to execute the command handler in a new context every time a command is sent. I am not sure if there's even a language that would support such approach... ;)

 

Anyway, I feel like you might be right and perhaps the domain shouldn't be that much concerned about granular error reporting after all. Letting the client duplicate some of the validation logic might not be as bad as I was seeing it. At worst, invalid client-side rules should not cause any data integrity issues.

[Kijana Woodard]

SomeCmd { string foo; string bar}

....

throw new ValidationException { Errors: { "foo" : ""Must contain a Q", "bar": "Must not be null or empty string" } }

[Alexey Raga]

When you do your "new BillingInformation(...)" and "new VisaCreditCard(...)", and "new Address(...)" it is kind of weird to me to pass some "result" in there to be populated.

Because in this way you _allow_ me to create invalid objects. These objects don't enforce their invariants, just populate some "results" they don't really care about.

More than that, you make your objects to be concerned about what to put in this "result" and in which format.

It is also very dirty to pass this "result" as you specified. For example, if the Address is created with an error (ok, it adds something to the "result"), then in your code it is used by the BillingInformation (because you pass it in the constructor), so the BillingInformation uses this Address internally, but it doesn't know that it is actually invalid! It may lean to some unpredictable exceptions or behaviors.

Or you will have to check your "result.ok()" all the time within every object in order to stop if there are invalid objects and to avoid touching them (because calling anything on them is unpredictable and can throw).

Or you will end up with some ugly "IsValid" on every object that you will have to check and track all the time to be sure that everything is OK.

It is hard to deal with things this way. That's why we say that objects are responsible for their invariants and that they enforce it. By doing this it will not be possible to have an invalid object, and it is good as it simplifies things a lot.

As @yreynhout mentioned, all this is not a concern of a command handler. Normally command handlers assume that the command is valid. It is up to the client to do its best to send a valid command. If it is not - the command is rejected and an exception is thrown. Sometimes we can make this exception meaningful, sometimes it is not critical and we just throw at the client because we don't want to spend time/money writing a code that explains some hackers why their commands fail :) Again, sometimes we do (I don't bother most of the times because it is client's responsibility to comply with the contract and to ensure that the specification is followed).

Why not enforce invariants in these objects, so if something is wrong they just throw?

For example, your VisaCreditCard constructor may throw "InvalidCreditCardNumberException", your BillingInformation can throw "AddressDoesNotMatchException", whatever? Then you just don't need your "result".

As a last resort I see creating some command validators (never actually did that, but have heard that people do it sometimes). You can even use the same code (put it in another nuget package, or even in the same assembly with your contract) in your handlers and in your clients (assuming it is the same tech stack).

But I really think we are over-complicating things a lot with all these validators, results, etc :)

Cheers,

Alexey.

[Alexandre Potvin Latreille]

@Alexey Yes, passing a collector around is an idea I had while writing back my answers yesterday in the search of an alternative, however after reading your response and thinking more about it this morning, I can see that it wouldn't work mainly because we couldn't expect what would happen when the value objects will be used if they contain invalid data.

If I have to implement this, should I then enforce invariants within value objects/entities, construct them one by one within a try-catch block and let my command handler build an error report that can then be returned to the client?

Also, where should rules such as, "the billing information for this card aligns with what the bank says" be normally enforced? Should I create a specification and use the specification from inside the command handler? Is that the correct approach?

Finally, in my search for a minimal duplication approach, I thought about having a rules store of some kind that could be used by entities/value objects internally to enforce their invariants. The rules could then also simply be exported to the client rather than being duplicated. Would it be bad to couple entities/value objects with such object?

Thanks again for the useful insights everyone has been giving so far.

[Kijana Woodard]

Remember that being DRY via code reuse is a form of coupling. Use with caution. Those rules may not be as duplicative as they appear during the brainstorming phase.

Where/how to handle the billing address invariant is a question for stakeholders. Do you want me to reject the order in this case and possibly lose the customer completely or should accept the order and handle the billing issue through a different channel: email, phone call (chance to upsell!), etc.

--

[Alexandre Potvin Latreille]

I read the validation chapter of Implementing Domain-driven Design (IDDD) by Vaughn Vernon again and while I think I may have finally discovered an acceptable solution to error reporting, I wanted to know the opinion of other DDD practitionners on the subject.

 

In his book, Vaughn says that using a validator class from inside an entity doesn't violate the single responsability principle since the validation process is handled by the validator class. The entity only knows how to resolve which validator class to use, which removes that burden from the client.

 

The pattern may look like:

 

public class Person {

    ...

    public void validate(ValidationNotificationHandler handler) {

        (new PersonValidator(this, handler)).validate();

    }

}

 

public class PersonValidator {

    ...

    public void validate() {

        this.checkForSomeRule();

    }

 

    protected checkForSomeRule() {

        if (this.person()...) {

            this.handler.handleSomeRuleBroken();

        }

    }

}

 

Now, I have a few question about this approach:

 

- Would there be any incentive using it for value objects as well, where the value object couples to an external validator class (just like the entity) which is used from the value object's constructor? However we would just throw an exception like SomeRuleBrokenException rather than informing through a handler because it seems more appropriate for value objects.

 

- In his example, Vaughn implements a single validate function on the entity, but I believe there might be different validations to run against the entity depending on the context or operation. Would it be acceptable to have some methods like validateForSomeOperation on the entity itself that the client could call before invoking an operation on the aggregate, or perhaps use an approach where the operation method itself uses a validator object to check wheter the operation is valid or not and allows the client to pass in a ValidationNotificationHandler to the method. Something like public void doSomeTransition(ValidationNotificationHandler).

 

I see three main advantages using this pattern:

 

- The validation logic can evolve independently of the entity.

- The validation logic can be reused outside of the entity.

- The application service can return a detailed error report to the UI by either collecting errors through a ValidationNotificationHandler or by using a try-catch collect approach for value objects (unless these are constructed directly inside the entity?).

 

However I would like to know if there are reasons I should avoid that approach? One issue that I see is that entities and value objects would be coupled on validator classes, but I am not sure if that alone is a reason not to use this approach?

 

Thanks!

[João Bragança]

" but I believe there might be different validations to run against
the entity depending on the context or operation."

This hits the nail on the head. The simplest thing to do is to put the
validations at the top of the operation. How would you re use
validations for 'Person' on another class?

To put this another way, what classes exist in netfx to validate
another class in mscorlib or System? Do you do var ts =
Timespan.Parse("Q"); new TimespanValidator(ts).IsValid() ? Don't get
me wrong, there are cases where you do need this but they are
extremely rare.

If you really need to display everything that's wrong with all the
inputs into a method, just collect them in a list. At the end, if the
list count > 0 throw your exception that takes the list as a
parameter.

This example doesn't explain what behaviors were executed on Person
that allowed it to arrive in a potentially invalid state.

On Wed, Jan 22, 2014 at 12:02 PM, Alexandre Potvin Latreille