All that said is true and sound. In a typical application, the data and their integrity are crucial. So we provides constraints and rely on them in a layered fashion and in the following order:
- Application Layer (e.g. Controller, LiveView, etc.)
- Business Layer (e.g. Context, Genserver, etc.)
- Database Adapter Layer (changeset validations)
- Database Layer (db constraints)
So that each layer above is not required to repeat any constraint already expressed below and if it does, it is just for handling better responsiveness or error prevention and not for preventing disaster and missing consistency.
All this topic is about the two middle layers and their inter-relation. Of Course the safeguard is playing their roles and being overly defensive or obsessed is not considered.
All that matters is providing discipline in code flow (especially in a team) and promoting reusability and unification over curated validations. And also letting the Business Layer to play its role; not as a rule but as a flexibility and keeping concerns.
