Architectural Validation Issues

Question

Architectural Validation Issues

Navigation

#1 by (2 votes)

2

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

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

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

1) Create a specific type of Exception (EValidationException)? And from this could the higher layers create code to trap and display error messages?

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

2) Create an Application Context type 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'm going to point out that I'm developing in Delphi and my project uses a layered architecture like DDD layers (I'm not using DDD 100% yet, I just use some ideas). In this case I'm calling my validation code in the application services.

asked by anonymous 19.05.2015 / 19:02

1 answer

How to traverse a vector with the quantity of the second vector? How to catch an error occurred on a webapi server?

score 2 · Answer 1

Since every application action reflects somehow on the business layer, and for security validation must be done at least at the business layer, I do not see how a validation can be restricted to the application layer. By the way, its rules are defined in one or more layers of business.

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

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

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