title: Is it good practice to seperate DataContract objects from my "Domain" objects in a WCF service?
body: <p>I'm currently part of a project in which we host a WCF service to be accessed by certain clients. The WCF solution is split up into 4 different C# projects:</p>
  
  <pre><code>Host.csproj
  DataContracts.csproj
  Infrastructure.csproj
  Model.csproj
  </code></pre>
  
  <p>Upon joining this project, I immediately wondered why there was a separate project for "DataContract" objects and one for "Model" objects. The two projects basically contain duplicates of the same objects. For example, in the DataContract project, there is a Customer object with 4 properties, and the model project also has a Customer object with the same four properties... I noticed that there is A LOT of automapper (mapping) being used in the application code to map datacontact objects to model objects and then re-map model objects back to data-contract objects while flowing through our typical service-repository pattern. The number of mappings necessary to produce results in this service has become extremely annoying. </p>
  
  <p>After asking some teammates about why this route was chosen, I was told that datacontracts should not contain domain logic and that they are strictly objects to be used to send over the wire (and that all domain logic should be done using the model version of the object). </p>
  
  <p>I feel like this approach is a bit unnecessary. Couldn't we just do away with the datacontracts project and use our model objects for both domain logic on the service side and also as datacontracts?</p>
  
  <p>Somebody enlighten me...</p>