I'm not sure that your remark regarding a data service layer is any different than the coding practices associated with any shared or common reusable service. My take on this is to reduce the number or quantity of abstraction levels within your code. My perspective of developing a data services environment is to ensure that all code that communicates to the defined interface is self-contained (prior to passing the data to the interface). In the days of writing shared components (shared code libraries, objects, etc.), problems would inevitably crop up when someone changed the underlying code without telling anyone else. The focus should be to only interface to shared or common services that don't change.
Dig Deeper on SOA data services and architecture
Related Q&A from Evan Levy
Learn the difference between change data capture (CDC) and data federation. Find out how companies can use both data integration technologies to ... Continue Reading
With Software-as-a-Service (SaaS) applications growing in popularity, learn about the SaaS data integration challenges companies should be aware of ... Continue Reading
Find out if real-time data integration applications has more data quality issues than other approaches. Also, see if real-time or near-real-time ... Continue Reading