C# – DDD/SOA in (.NET) MVC and Message pattern(s) / Request Response

asp.net-mvccdomain-driven-design

We're currently considering whether it makes sense (or if the benefits are worth the added code) to introduce a Message based pattern (such as Request Response) into a Domain Driven Design / Service Oriented Architecture under an MVC app (with DI and potentially used by MVC, WCF, Windows Services, etc.).

Basically (in MVC) the controller uses an injected service which in turn uses an injected repository to save/update/delete objects.

There are Application Services, and Domain Services and the application service might use multiple domain services to e.g. save something and then send an email about the item being saved.

Considering the example use case where something is saved and then an email is sent, it could be useful to present any potential errors to the user such as "Save succeeded, but the email wasn't able to be sent. Please try again in 5 minutes or contact support etc." vs just a generic error such as "Save or email didn't succeed".

The message based pattern with Request and Response objects seems fine (in theory), or at least the response objects with e.g. a couple inherited fields could be useful.

public abstract class ResponseBase
{
    public bool Success { get; set; }
    public string Message { get; set; }
}

Then there could be an object to extend it with the ViewModel result as a property and finally the controller could decide whether to show e.g. an error message, or update the view etc.

This seems nice, but in the simple cases where you are simply saving an item and it's clear the save succeeded or failed, it can also seem to be overkill. Creating and passing extra objects where maybe you just need an ID and a Boolean seems to make this pattern redundant. The thing is that this object needs to transfer from the controller, through the services, down to the repository, and back. The request part could be possible to ignore and only worry about returning a meaningful result too.

It's hard to estimate whether it could be 50-50 or 40-60 where this type of system could be useful, but there are many cases that could use it, as well as many that aren't very useful.

Is there better approaches to this issue, or have you found this pattern useful for the scenario portrayed? Is it worth the extra coding for the simple cases (in your case(s))?

Best Answer

Another option would be to throw custom exception in your domain service as soon as something go wrong and catch it, preferably, in your model builder. That way your actual code is still valid, but rather having to pass some sort of extra objects just to deal with error messages, you just throw an exception and catch it at the right place. Of course, keep on handling all unhandled exceptions (things that are not supposed to happen) in the Application_Error method as you probably do right now.

Here’s an example:

public ActionResult Deposit(DepositModel model)
{
 // Some code...

 try
 {
  var depositResult = _cardDepositService.Perform(someParmaeters);

  // Some more checks...

  // The deposit has succeeded
  return DepositSuccess(model.Amount.DepositAmount.Value);
 }
 catch (DepositAmountException ex)
 {
  this.SetPopupMessage(ErrorMsg.DepositAmountError);
  return PartialView("DepositPanel", model);
 }
}

There are several ways to handle errors in MVC apps, feel free to manage them your way ;-)

Hope that helps!

Related Topic