Data Contracts vs. Domain Objects
In this post I want to cover the differences in the usage of data contracts and domain objects. I have seen a few times that people are mixing up the two concepts. With this post I want to explain why data contracts and business objects should be treated as a separate things and not be merged.
Let’s start with an example: Assume that we want to create a centralized application that provides us with information about music (such as the CDDB). For this application we might want to have a web interface and – we focus on this – a web service (e.g. using WCF) which can provide information about music (artists, albums, tracks) to other applications.
A possible domain model for this application would be the following:
For simplicity I only show the properties. We can assume that each object would have some methods containing business logic as well as methods for persistence (CRUD). Those methods would normally call the data access layer which could be realized with an O/R mapping framework such as the Microsoft Entity Framework or NHibernate for example.
Now we want to provide a service that allows us to search and retrieve artists, albums and tracks. The service and data contracts could look like this:
One could argue now that those classes look exactly the same like the classes of our domain model, except the missing methods. Why should we not expose the business objects in our domain model directly?
There are several reasons:
- The main reason probably is that if you use the business objects as data contracts (data transfer objects), it would tie our business objects to the service interface. This basically breaks all concepts of encapsulation. You might want to add/change some properties and classes to your domain model to support additional use cases. This would change the contract of your service and thus would need a change in all already existing consuming applications. Have a look at the following example: We want to extend our business model to support our music download website and attach some download information to a Track business object. If we would have exposed the business objects directly all existing service consumers would have to deal with the new service interface event if the information is not useful for them, because we only use it for our commercial web site.
- Secondly the data contract by definition defines the communication format. It should only consist of public properties. Also in service oriented architecture (SOA) it is common that a data transfer object contains a sub set or super set of the information provided by the business objects in order to minimize the traffic (requests which need to be sent to service). You can see that there are minimal differences between the domain model and the service contracts/data contracts.
Therefore we keep mapping data contracts to business objects and vice versa!