I've been doing some reading on Domain Driven Development but can't see how this would really change any development practices, besides maybe keeping our domain object names insync with elements in our requirement documents.
For those really into DDD, how has this change your development pracitces?
The thing I found about DDD is that it merely gives names to the concepts and principles I used already. To be useful it does not have to change the way we develop systems, it can just provide us with the terminology to discuss our approach.
The few things that changed for me after reading Domain Driven Design Quickly are:
I now identify aggregare roots, entities and value types.
I have embraced the repository pattern along with nHibernate for implementing the persistence layer. (This is because this ORM feels like a good fit to me when implementing aggregate boundaries)
I embrace the use of an ubiquitous language, you elude to (probably the most important change I made).
Other than that, DDD has merely formalised what I thought of as common sense.
Not quite an answer to your question, but...
You've glossed over a key point: a person/team created the content for your requirement documents. But how did they arrive at the conclusions in that document? Are they presenting facts, or merely their understanding of the problem space. Is it possible that parts of the document are wrong? Or that the requirements have changed since the document was created?
The fact is, DDD kicks in before you start writing code. Eric Evans wasn't suggesting that DDD is a solid way to write code; DDD is a solid way to identify the business problem, and bring clarity to the people involved. The implementation part is secondary.
If you're in a position where someone else creates accurate requirements, and you code up a solution, then great. But if your're in a position where you have to understand the requirements (and you aren't an expert in the business domain), then the fundamental essence of DDD can change your approach.