Agreed with different levels of validations. Though typically I've heard the "incoming communication layer" referred to as "system boundary", to avoid confusion when discussing things like layers in a layered architecture, where the layers are generally implied to be "stacked" top to bottom.
As a heuristic for what validation goes at the infrastructure layer/system boundary, I guide teams with the question "do I need external information to perform this validation?". Typically, the shape of data, data schema, and simple bounds checking should be done at the boundaries of the system. This has the added benefit of improved performance by avoiding unnecessary database queries and API calls if we can tell right away that a request or input is not valid.
Passionate about technology, computing, and software development. Experienced in coding and system design, with a love for Golang, DDD, and clean code.
Hey, thanks for the feedback. I agree that "do I need external information to perform this validation?" question is actually the one that should give information about logic placement. Bounds checking is a place when it becomes a bit tricky.
For example, in provided example - user age. Does the infra layer have enough information to validate it? It can check basic contract requirements, e.g. this field should be in age field of JSON payload, it should be integer and it must be provided. But the check of actual age - here when it falls into domain layer, since infra layer does not have enough information (and should not) - what age is allowed? Is it 18-60? or 18-110? or 21-110? This validation highly depends on the domain rules and can't be placed in infra layer (system boundary) without domain logic leak.
That's a great point, and I agree the domain logic should not leak in to the system boundary / infra layer.
In my experience, the answer is that any particular field or validation doesn't have to exclusively be validated in one part or another. To take the same example, my answer would be two fold:
infra layer: Validate the age is present and is a positive integer.
domain layer: Validate the domain-specific rules for allowed ages for users.
Passionate about technology, computing, and software development. Experienced in coding and system design, with a love for Golang, DDD, and clean code.
Yes, 100% agree. The main point is that this is a question of code responsibility. It is not about specific fields, but more about the validation scope that can be done in specific place while still having strong boundaries between layers.
Some pieces of validation can be even duplicated, e.g. domain logic can be called not from infra, but from another domain service, and proper validation still should be applied. So here is the question - what can/should be placed in infra layer and for what reason -IMO it is almost always a question of optimization.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Agreed with different levels of validations. Though typically I've heard the "incoming communication layer" referred to as "system boundary", to avoid confusion when discussing things like layers in a layered architecture, where the layers are generally implied to be "stacked" top to bottom.
As a heuristic for what validation goes at the infrastructure layer/system boundary, I guide teams with the question "do I need external information to perform this validation?". Typically, the shape of data, data schema, and simple bounds checking should be done at the boundaries of the system. This has the added benefit of improved performance by avoiding unnecessary database queries and API calls if we can tell right away that a request or input is not valid.
Hey, thanks for the feedback. I agree that "do I need external information to perform this validation?" question is actually the one that should give information about logic placement. Bounds checking is a place when it becomes a bit tricky.
For example, in provided example - user age. Does the infra layer have enough information to validate it? It can check basic contract requirements, e.g. this field should be in
agefield of JSON payload, it should be integer and it must be provided. But the check of actual age - here when it falls into domain layer, since infra layer does not have enough information (and should not) - what age is allowed? Is it 18-60? or 18-110? or 21-110? This validation highly depends on the domain rules and can't be placed in infra layer (system boundary) without domain logic leak.That's a great point, and I agree the domain logic should not leak in to the system boundary / infra layer.
In my experience, the answer is that any particular field or validation doesn't have to exclusively be validated in one part or another. To take the same example, my answer would be two fold:
Yes, 100% agree. The main point is that this is a question of code responsibility. It is not about specific fields, but more about the validation scope that can be done in specific place while still having strong boundaries between layers.
Some pieces of validation can be even duplicated, e.g. domain logic can be called not from infra, but from another domain service, and proper validation still should be applied. So here is the question - what can/should be placed in infra layer and for what reason -IMO it is almost always a question of optimization.