The Clean Architecture: Where should we put validation logics in the code
When working with Clean Architecture, I sometimes wonder where should I put validation logics in the code. In this archicle, I'll try to conclude where should we put validation logics in the Clean Architecture.
I think, the question "where is the correct place of the validation logic" is wrong. We should put the validation logic to each layer of Clean Architecture.
The meaning of the word "validation" is very vast and ambiguous because it has different meanings
depending on its context.
Nevertheless, we tend to misunderstand that the "validation" is just single role. But actually it's
not. Just as Clean Architecture splits the responsibility by layers, each layer has its own
In each layer, the system should reject the input which breaks its layer's responsibility. This is validation. So the meaning of validation is differrent depending on its context.
In Clean Architecture, a certain layer should NOT have validation logic which is not responsible for its layer. Otherwise, the problems I'll write later will occur.
Validation is just specification
We should NOT think that specification and validation are different things. Validation is just specification. The validation is just a subset of the specification.
For example, the specification
the client can request with JSON data means the existence of the
the not JSON data will be rejected. Thus specification and validation is essencially
same. The validation is naturally derived from the specification.
That's all of the concept of this article. Next I will discuss about concrete validation in each layer of Clean Architecture.
Validation in Frameworks & Drivers layer
This layer is most outer layer in Clean Architecture. Actually we don't write much code by ourself in this layer, but validation does certainly exists.
For example, nginx will return
413 Entity Too Large if the request is too large. This is a kind of
The other is verification of request reliability by SSL/TLS.
In this layer, validation means protecting the system at low level.
Validation in Interface Adapter layer
The responsibility of this layer is converting data from one's format to another one's. For example, converting request body JSON into Java (or Ruby or ...) object.
For example. if JSON is malformed, system can't continue to convert data so we will throw error.
In this layer, validation specifies data serialization/deserialization protocol.
But in this layer, we should NOT validate character length or numeric ranges or non-null constraints, etc. It is not the responsibility of this layer. The responsibility of this layer is converting data format.
Validation in Application layer
In this layer, as validation, we must ensure that domain objects can receive the input. We should reject the input which the domain object can't be received.
For example, when some mandatory parameters are missing, it should be rejected because the domain object has no way to receive like that parameter.
Validation in Domain(Entity) layer
In this layer, validation is equivalent to domain rule.
For example, in banking system, the rule
It's impossible to withdraw much money than remained balance is exactly validation.
What is happen if we put a validation logic to wrong layer
Above I discussed about the validation in each layer.
By the way, if we mistake the placement of validation logic, what is happened?
When putting a validation logic more outer than correct layer
In such case, we will not be ale to keep DRY principle.
Code duplication and copy & paste will occur. And unexpected code which doesn't satisfy specification will be easily increased.
When putting a validation logic more inner than correct layer
In such case, we will struggle with restriction which is unneccesarry strong.
A restriction from validation logic will be broadly applicated even though you don't need it.
Validation logic is naturally derived in each layer's responsibility.
I think most practices of software design are origin from just a simple prinple, commonly known as Single Responsibility Principle.
Not validate, but just give proper specification and responsibility to each layer.