DAO Data Restrictions
When dealing with data you will be restricted by certain limitations regarding the type. For instance, when storing some string in a database as a VARCHAR you have to specify the maximum length. Even deciding between an int or a long decides on what the maximum and minimum values are. But sometimes your storage system (like the database) may be more strict than the language you use. An example of this is a string, which can be as long as it fits in memory, but in your database you have to specify a limit (depends on your database system), so what do you do with these restrictions?
Generally your domain has certain restrictions, such as a:
A discount always positive
Date of birth should be in the past
For these restrictions it makes sense to do them on your business domains, but do you also enforce them on the database level? Typically this is not something you want to do as this means you have to keep both of the restrictions in sync. Note that you will likely already have a duplicated check on these restrictions to prevent your user from submitting invalid data.
But when you have restrictions which are specific or required for your storage system (being it a database, some binary format, or something else), where do you enforce these? This are arbitrary restrictions which trickle down into your business specifications. Again, since you want to avoid the user from submit data you know will cause an error, you will add a rule for this in the front-end.
Just because they trickle down into your business specification (as they become a hard restriction), this doesn't mean you have to check them on the business domain. Since your storage system will raise an exception if your data is invalid, I don't see the added value of having the same check on your business entities. Again, if you do, then you have to keep them in sync if they ever change, for instance if your storage system allows to store more or different data.
After some period, you may even forget why certain restrictions are there, was it a technical reason, or a real business requirement? If you have these checks all over the place, you will not be able to figure it out, since they are both enforced on the domain level as well as on the storage level.
For this reason, I advocate to implement validation checks at the business level only for real business restrictions, and do the same for other systems (storage, or third party interactions). This allows a trace to always figure out why certain restrictions are in place, moreover they allow them to evolve easily with the system that enforced them in the first place.