Appendix E. Validation
Whenever we’re teaching and talking about these techniques, one question that comes up over and over is “Where should I do validation? Does that belong with my business logic in the domain model, or is that an infrastructural concern?”
As with any architectural question, the answer is: it depends!
The most important consideration is that we want to keep our code well separated so that each part of the system is simple. We don’t want to clutter our code with irrelevant detail.
What Is Validation, Anyway?
When people use the word validation, they usually mean a process whereby they test the inputs of an operation to make sure that they match certain criteria. Inputs that match the criteria are considered valid, and inputs that don’t are invalid.
If the input is invalid, the operation can’t continue but should exit with some kind of error. In other words, validation is about creating preconditions. We find it useful to separate our preconditions into three subtypes: syntax, semantics, and pragmatics.
Validating Syntax
In linguistics, the syntax of a language is the set of rules that govern the
structure of grammatical sentences. For example, in English, the sentence
“Allocate three units of TASTELESS-LAMP to order twenty-seven” is grammatically
sound, while the phrase “hat hat hat hat hat hat wibble” is not. We can describe
grammatically correct sentences as well formed.
How does this map to our application? Here are some examples of syntactic rules:
Get Architecture Patterns with Python now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.
