How can lightweight units of business logic be positioned as effective reusable enterprise resources?
Problem
A service consumer that requires access to a business entity information (such as data about an invoice) needs to maintain two identifiers: one for the service and another for the invoice itself. The business entity identifier is typically unique only within the scope of the service contract, and the service consumer is commonly limited to overly coarse grained service capabilities offered by the service contract.
Solution
Expose data and functionality associated with business entities as a series of granular, lightweight endpoints.
Application
Break up the service contract to expose service capabilities based on fine-grained resources (lightweight endpoints) associated with the business entity.
Each resource operates only over the identified business entity or document. Service consumers and all messages exchanged by the services refer to the business entity using the corresponding resource identifiers.
Impacts
Finer grained service capabilities can result in verbose resource identifiers that may impose a greater governance burden.
Applying this pattern to can lead to resource overlap in order for multiple service capabilities to offer access at multiple levels of granularity. For example, an invoice and properties of the invoice can be exposed as separate resources, even though they refer to a common set of underlying information or functionality.
Greater effort may be required when applying Service Facade, when the facade relates functionality associated with granular resources to core service logic.