Where’s the model? Is it the code or something else?

A few weeks ago I had a very interesting email exchange with Jeffrey Palermo in which he raised some important questions about the Entity Framework. Here’s an excerpt from his original query (used by permission):

I've been thinking a lot about the model of the problem domain for a piece of software and the question of "what is the model". In domain driven design, the domain model in code is the canonical representation of the thoughts and concepts of the business domain (the model). Even so, the code is a very good _representation_ or _translation_ of the model as discussed by business analysts (it encorporates the concepts (entities) and behavior and rules of the business domain). The database schema is another translation of this model, but only geared toward storage of the concepts or entities. The behavior is absent here, just storage (for the most part).
This new EDM concept your team is introducing seems to be aimed at being the new canonical representation of the model. Here, there is an Xml file which describes the model or _represents_ the model, but is not the model itself. I remember when UML was really big, and folks were calling that the model. It could be described so well that it was called the model and all else was secondary. In the end, the UML wasn't executable, wasn't verifyable and wasn't testable, so it lost mindshare because when it came to working software that handled the business domain correctly, it still didn't deliver. There were tools that sought to generate software from the UML, but again, it didn't work.
I'm having a problem with your EDM xml file because I respect history. The Xml file that represents the model: how do we test it? How do I _know_ that it's correct? that is contains the right concepts (entities)? that every bit of it's behavior is correct? That every one of its rules is right?
I respect the coded domain model so much because it can't lie to me. I run my unit tests, and they pass or fail. I can demonstrate it. I can objectively prove its behavior and rules. The best representation of the model has to work 100%.
Maybe you've thought about this and have an answer. I've heard said that this new Xml artifact will be called "the model". Is that really the intended noun?

My response was that I hear and share concerns about the parallels to UML and the failed efforts of the past to make UML the center of the universe. (I personally think codegen from UML is so evil that I have taken to calling UML "the enemy" not because it's original purpose and ideas are bad—it can be a great tool for doing some sketches to communicate some ideas—but because it has been perverted to evil ends.)

We do talk about the EDM for an application as "the model", but that's just a verbal short-hand for "data model", which I believe is a critical distinction. We are explicitly NOT trying to define behavior in the EDM. The code is the right way to define that. We are, however, trying to define enough about the structure and constraints on the data that we can provide a rich set of services in a general fashion that still honor those constraints. If you think about it, this is very much like what the relational model does today vs. just doing your own file format. The relational model allows you to describe some things about the structure of your data so that the database and other parts of the system can provide services which help you manage that data. The idea of the EDM is to provide a higher-level of abstraction that gives more information about the structure of the data so that we can provide more services. This doesn't replace the object model or reduce its critical role; it just augments it with new services.

 Once we start generating code from the EDM, things definitely become blurred a bit, but the explicit goal of the generated code is not to replace your object model—it's to save you some typing of repetitive things when you are building that object model. Further, the intent is that we would not require this generated code—you can always build your model completely on your own and just align the EDM with the shape of that model so that you can take advantage of the EDM-enabled services we provide (right now that means persistence/query, but eventually that means other things like reporting, replication, remoting, etc.).