Architectural validation issues

Question

I was thinking about how validation is applied in different scenarios and mainly using layered architecture and I came across some issues that I would like to discuss.

Are there any validations that should be used at the application level and not at the business level? If they exist, then they should not be forced on the entities but on the application layer above.

When we find errors in validation how we should propagate these errors to the upper layers?

1) Create a specific type of Exception (Evalidationexception)? And from that the top layers could create code to intercept and display error messages?

try
    customerService.registerCostumer(name, phoneNumber, email);
except
    on E:EValidationException do
        Self.ShowValidationMessages(E.getErrorMessages());
end;

2) Create a type of Application Context that would be injected into Application Services and serve as a bridge to validation errors?

validator := TValidator.Create;
//in service layer
if validator.isValid(customer) then
   FApplicationContext.addMessages(validator.getErrorMessages());

//in presentation layer (a form for example)
if applicatioContext.hasErrorMessages() then
    Self.ShowValidationMessages(applicationContext.getErrorMessages());

I’ll point out that I’m developing in Delphi and my project uses a layered architecture like the DDD layers (I’m not using 100% DDD yet, I just use a few ideas). In this case I am calling my validation code in the application services.

Answer 1

As every action of the application reflects somehow in the business layer, and that for security the validation should be carried out at least in the business layer, I do not see how a validation can be restricted to the application layer. Because, its rules are defined in one or more business layers.

Your two solutions to return errors to the top layers of the application are valid. However, I believe that the first solution is more appropriate in most cases.

Your second option generates user-facing error messages at the same level as the problems arise. In my view, this reduces the cohesion of the layers, since an inner layer this generating information that are inherent in higher layers (user interface is not the responsibility of the business layer, for example).

The first option, however, is more cohesive and does not increase the coupling more than the second option. Error reporting is then performed through a structure that allows you to describe the error and its conditions in an easier way to manipulate in code. So the application layer can generate the most appropriate message.