Member-only story
Methods to Separate Syntactic Validation From Business Validation Without Duplicate Chaos
Source: Methods to Separate Syntactic Validation From Business Validation Without Duplicate Chaos
When you inherit a codebase where the same rule is validated in five layers — client, controller, service, repository, and then finally by the database constraint — you feel the pain: bug reports, subtle races, and duplicate test effort. That pain is an opportunity to design a clear contract between two different kinds of validation so they complement rather than duplicate each other.
1. Why separate syntactic and business validation?
There are two different concerns hiding behind the single word “validate”:
- Syntactic validation — input shape, types, lengths, formats. These checks are deterministic and cheap: does the phone number match the regex, is the email non-empty, is the JSON schema correct?
- Business validation — domain rules that require context or external resources: is the email unique, does the user have sufficient credit, is the requested SKU in stock?
Keeping them separate prevents duplication, reduces latency by short-circuiting cheap failures, and clarifies responsibilities for teams and tests.
1.1 A simple mental model
Think of syntactic validation as shape and format guarantees and business validation as semantic…
