A data layer is all about abstracting the explicit boundary between the application/ domain model and the persistence datasource. 

 

Although this boundary can never be totally transparent, the data layer does its best to expose the persistence data in a way which can be easily and suitably utilized by domain model.  A simple example is accessing a file through a reader interface which abstracts the user from the underlying details of reading a file from disk.  A more complex example is accessing relational databases which abstracts the user from the underlying storage mechanism and enforces a number of domain specific rules in an effort to keep shared data consistent.

 

This requirement is totally orthogonal to whether SOA or traditional 3 tier architectures are being utilized.  I am continually amazed how various people in the industry are suggested that SOA means the end of objects and the data layer.  To me, a vast majority of services are going to be written in OO languages and still need to persist data.  I suppose one could say that data persistence will just be another service (a very special service at that) – but this is just adding a façade to the same requirements and the same code.  In fact, I would guess that a significant amount of ASP.net code is doing this precise task on multitudes of production systems today.