title: EF 4.2 Code First and DDD Design Concerns
body: <p>I have several concerns when trying to do DDD development with EF 4.2 (or EF 4.1) code first. I've done some extensive research but haven't come up with concrete answers for my specific concerns. Here are my concerns:</p>
  
  <ol>
  <li><p>The domain cannot know about the persistence layer, or in other words the domain is completely separate from EF. However, to persist data to the database each entity must be attached to or added to the EF context. I know you are supposed to use factories to create instances of the aggregate roots so the factory could potentially register the created entity with the EF context. This appears to violate DDD rules since the factory is part of the domain and not part of the persistence layer. How should I go about creating and registering entities so that they correctly persist to the database when needed to?</p></li>
  <li><p>Should an aggregate entity be the one to create it's child entities? What I mean is, if I have an <code>Organization</code> and that <code>Organization</code> has a collection of <code>Employee</code> entities, should <code>Organization</code> have a method such as <code>CreateEmployee</code> or <code>AddEmployee</code>? If not where does creating an <code>Employee</code> entity come in keeping in mind that the <code>Organization</code> aggregate root 'owns' every <code>Employee</code> entity.</p></li>
  <li><p>When working with EF code first, the IDs (in the form of identity columns in the database) of each entity are automatically handled and should generally never be changed by user code. Since DDD states that the domain is separate from persistence ignorance it seems like exposing the IDs is an odd thing to do in the domain because this implies that the domain should handle assigning unique IDs to newly created entities. Should I be concerned about exposing the ID properties of entities?</p></li>
  </ol>
  
  <p>I realize these are kind of open ended design questions, but I am trying to do my best to stick to DDD design patterns while using EF as my persistence layer.</p>
  
  <p>Thanks in advance!</p>