The Difference between Validation and Business Rules

In software development, two concepts still cause considerable confusion: Data Validation and Business Rules.

I’m here to break these down for you so that you understand the difference by the end of this article.

​

Validation and Business Rules

I recently watched a YouTube video where the person talked about the difference between data validation and business rules in software systems:

For data validation, they declared:

– It’s about checking data as it comes into the system.

– Think of it like simple checks on the data (like ensuring quantity > 0).

– These validation checks rarely change.

​

Now, for business rules, they explained:

– Business rules are more flexible and depend on what’s happening in the system, e.g. quantity < availableStock

– Business rules are part of the system’s core Business Logic.

​

And on these last points, my view differs.

Differs how?

Mainly insofar as I consider data validation part of the business rules.

Validation is Business Rules.​

Let me explain my position.
​

First, I love Clean Architecture. Therefore, I prefer to write the code for my business logic workflows before anything else, like data access code or UI/API. In this way, I am virtually assured of producing business logic decoupled from application type and the database.

​

Because I write the business logic workflow first, I want this programming artefact, and its associated classes, to be self-consistent regarding all internal processes, including validation and business rules. In other words, I want Business Logic to check that the data is valid regarding what the workflow requires. Business Logic should not depend on prior data validation checks.

​

Second, let’s consider a scenario where we did put the data validation into the UI for a desktop app. What kind of obvious problems would this create?

​
Since busines logic stands alone, we can easily shift it from one application type to another – in our example, from the desktop app to a Web API.

​​Suppose we have the validation rules embedded within the presentation layer, and we decide to host the BL in another application type. In that case, we must re-create the validation rules in the new application.

​
Do we want that? Probably not.

​

I like my full set of business rules to be complete and self-contained in one place, the central business logic.

​
Nonetheless, there are also advantages with validation logic in the presentation layer:

• Putting data validation into the presentation layer allows us to easily associate data validation failures back to incoming data fields. The same cannot be said for validation logic in the Business Logic, which is ignorant of the specifics of the input data models.
• We can duplicate basic data validation in the UI / API as an optimisation to counteract the shortcomings of validating in core business logic. I do that for basic data validations, eg. required fields. Does that mean that I will then go ahead and remove the validation code from business logic? No, I don’t. Sure, it won’t get called in this application, but it can sit there as a guarantee of data validation in case the business logic gets ported to another application.

​
Conclusion

Data validation might be so simple it seems to have little to do with business rules. But that is not the case. If an incoming quantity data point has to be greater than 0 to be valid, that is a clear expression of a business rule.

​

Again, data validations are business rules.

​

And as such, they belong with the other business rules in the core Business Logic.