title: DDD Seperation of Domain Objects and EF Entities
body: <p>In a recent upgrade from EF4.0 to EF5.0 and Code First some of the rules to get the Domain Model to play with Code First our team decided to split our concerns by making POCOs of the persistent object representing a 1 to 1 mapping of Databse Columns and relationships within these persistent POCOs. Using FluentApi configurations for each persistent object we tentatively called these 'persistence objects'. Some Domain objects split across several of these persistent objects utilizing abstract classes, several interfaces and sepcifications from the business rules. Since DDD refers to Domain Business Objects as 'Entities' we found this confusing since EF refers to Entities. We placed the POCOs in a separate library project. To me they began to look like DAOs.</p>
  
  <p>Given the above is the choice to separate the Domain Object from the persist-able POCO contract for Code First?</p>
  
  <p>The objection I raised is that this would mean the persistent objects would be exposed as a WCF Data Service objects. I halted the development until we have a small working version (our core objects can be pushed to 5 tables and 3 domain objects). I didn't want to move forward with the other 70+ POCOs until I knew for sure this was a best practice or better yet another way that fits more akin to Eric's outline in the blue book.</p>