Data Contract Design Guidelines

1. Avoid namespace conflicts
   Name your data contract to avoid conflicts with the application layer. Get used to using the following naming convention for your data contract: EntityNameData, where EntityName matches with the coresponding entity.
2. No business rules in data contract
   The data contract should only define the types allowed to be used by the service, not business rules.The reason that WCF does not support XSD restrictions through data contracts out of the box is that implementing business rules through schema design is an expensive way to implement business rules, because if a rule changes, the schema must be changed, and thus calling clients must be made aware of the change. A better way to implement business rules is within the service implementation itself. This way, changes in business rules do not affect contract designs and services become cheaper to maintain going forward.
3. Avoid Object Orientated approach
   When you design a data contract, you are creating a schema, not an object model. This means that while the entities in your application are likely to use inheritance, this approach does not make sense for the generated schema you are creating. Always review your generated schema using svc to ensure that the contracts create a clean WSDL with clean XSD schemas.
4. Entity Translator
   http://msdn.microsoft.com/en-us/library/cc304747.aspx
5. Service Interface
   http://msdn.microsoft.com/en-us/library/cc304866.aspx
6. Exception Shielding
   http://msdn.microsoft.com/en-us/library/cc304697.aspx