Out of the box, SharePoint gives you many ways to manipulate it's data - through the API (tons of code classes whose names begin with SP
like SPSite, SPWeb
etc). This API is however accessible only when you run code on the server.
If you wan t to do something on the client side, you can use SharePoint's web services or WebDAV.
However, it would be awkward to use the Web service API if you execute the code on the server itself.
So, if I had to create an application that has both web application AND a desktop application, I would make my own class library with domain-specific objects inside that that exploit the possibilities of regular SharePoint API. I would then make some part of my class library available to desktop client applications as SOAP Web services (these would be more specific than the ones built into sharepoint, such as "lists.asmx") and would provide the client with the functionality it needs. If I needed to call the same method from the web application, I wouldn't use Web services, but rather load my assembly from GAC and call into it.
After I wrot all of it, I think this is something more than simply 'data layer', since data layer wouldn't normally contain business logics.