Your database is just about the worst place in the world to be strict about DRY. It turns out, your model and validations don't actually prevent broken data. They just make you think you're safe from it...

...until your broken data starts biting you and your customers in places that don't typically see sunlight.

>Your database is just about the worst place in the world to be strict about DRY.

There are no places in any code base at all where it doesn't pay to be rigorous about DRY.

>It turns out, your model and validations don't actually prevent broken data.

A) DRY isn't about preventing broken data.

B) Validations are for preventing broken data. That's what they do.

DRY is the reason I write a remote facade. Security (e.g. sanitizing inputs) is less-repeated at the database boundary than at myriad application/ORM implementations.

>DRY is the reason I write a remote facade.

Remote facade sounds like a lot of boilerplate to me.

It truly varies. If all you're doing is sanitizing a simple INSERT, it's almost pure boilerplate, but that is not a very interesting or common case.

I'll offer some of the reasoning that got me to building remote facades. The database needed to sanitize its own inputs; we could not trust application developers with that. There would be multiple client-languages (Ruby, Python, Java, for starters) and I wanted to keep domain adapters for those languages simple as possible. The database would be changing regularly, and many changes could be simply absorbed in the remote facade, so applications depending on the remote facade via their client-language libraries would be somewhat insulated.

Now, it wasn't a perfect regime, and nothing is. But it paid the bills for years and my schemas are still in play at that place.