In their book "Enterprise SOA: Service-Oriented Architecture Best Practices", Krafzig, Banke and Slama define a "facade service" much like what the other posts describe. Such services "encapsulate some of the complexity of underlying basic services by providing an aggregated API that enables clients to more easily utilize the functionality of the basic layer."
I know you were just providing an example with the 10 fields vs. 15 fields scenario but we should be careful about thinking in those terms. Rather, we should be thinking in terms of services. For example, from the Enterprise SOA book, they use an example of separate booking and billing services that must record a reservation in a coordinated manner--e.g. you don't want to book without billing and vice versa. An intermediate service would be one way to address this. This focuses on the need for coordinating the services, rather than focusing on the data elements. -Rob
