Views might work for a small subset of DDL changes since views are rarely update-able when based on more than one table. How can you handle a case where a denormalized child table column gets moved up into a parent table?

I queue up developer requests for a day, code and test locally, then deploy to development the next day. It breaks the app but all developers fix their stuff, check in, and get running again. The scheduled break and fix usually lasts less than an hour. I keep a full history of all DDL changes so I can apply them in order into other databases such as Testing, Staging, Production, etc.

Alternatively, if you have a stored procedure only interface to applications, you are completely free of the physical database design. This is the case for 90% of what I have.

I only use synonyms for objects external to the current database. I don't see how they would solve anything for a local schema change.