The expression “Domain Model” is one of the most abused expressions of the recent history of software. Everyone talks about it; everyone thinks everyone else is doing it and therefore everyone claims they are doing it. Yes, but how? Entity Framework and Code-First have a role in this. Built with the database persistence in mind, Entity Framework has never been sold for what it actually is—a plain simple O/RM. It makes a point of letting you use classes to express the domain and then persist it. This approach makes for intriguing demos at conferences but may not work as smoothly in the real world. And has little to do with domain-driven design and domain modelling. The point is not in how you write classes and partition logic around database tables. The point is how you organize the business rules and how you save, alter and read back the state of the system. Through a comprehensive and quite interactive example, the session will try to make two key points. A single model doesn’t fit all sizes of applications and the domain model is a quite a different thing that the persistence model that Entity Framework Code First is all about.