If your application has any reasonably complex data, validating that data when it is being added into the system (i.e. if it meets the invariants) prevents bugs

If your application has any reasonably complex data, validating that data when it is being added into the system (i.e. if it meets the invariants) prevents bugs later down the line. If the data is different to what the application expects, you need to spend time identifying that data, and correcting it. If the data is complex (e.g. book metadata) it can be expensive to correct. Having up-front validation of the input (e.g. checking book subject values) prevents a whole class of errors (such as spelling errors between country names), and enforces the contract between the data and application -- the list of things validated should be based on how the application works, such as required fields/values. If there is a new value that the business need, you then know you need to make an application change in order to support that value. Some values (like the list of countries) would be an open list, and would be best stored in the database/application as a list that can be updated outside of the code changes. Some other values (esp. those that need different code/logic to function) are closed lists that should be maintained and validated in the code (e.g. as enumeration values).