Service Layer Architecture
The ServiceLayer can be described as a layer of services on top of the persistence layer. The services themselves can be divided into subcomponents.
Components
Client
A client in this context is any software component that uses the ServiceLayer, such as:
- Page Controllers of an MVC framework
- Web Service clients
- Scripts
- Other services
Services
A service holds the logic to perform business processes and provides this logic through a number of related public methods. These public methods usually are defined in a Java interface. Most often these methods operate on the same kind of model object, for example product, order, and so on.
Services are expected to abstract from the persistence layer, that is, to only contain functional logic and no persistence-related code. That means if you implement a service, make sure to implement it in a way that the underlying implementation is as loosely coupled to the persistence layer as possible.
SAP Hybris Commerce exposes all of its functionality through services. The following kinds of services are available:
- Business Services implement business use cases, such as cart handling or back order.
- Infrastructure Services provide the underlying technical foundation, such as internationalization, import, export, and so on.
- System services provide functionality required by the ServiceLayer, such as model handling and session handling.
The service methods should be as fine-grained as possible to enable reuse.
Extensions must provide their functionality as services. Per extension you may provide as many services as you deem necessary, not just one.
Services may use other services to perform their tasks but should keep their inter dependencies to a minimum to avoid overly tight coupling with other components.
In a project, you may write your own services to either provide unique functionality or to aggregate other services' functionality.
Although technically not necessary, Hybris recommends implementing services in terms of interfaces.
Services interact with other components through models.
Strategies
A service may delegate parts of its tasks to smaller micro-services, called strategies. The service then serves as a kind of facade to the strategies. Clients still use the service and its stable API. But under the hood the functionality is split into multiple parts. Because these parts are smaller and very focused to their task, it is easier to adapt or replace them. Strategies therefore help to further encapsulate behavior and make it more adaptable.
DAOs
A DAO (Data Access Object) is an interface to the storage back end system. DAOs store and retrieve objects. You use DAOs to save, remove, and find models. DAOs are the place to put SQL or FlexibleSearch statements and nowhere else. This is to ensure further decoupling from the underlying storage facility. DAOs interact with services via models and with the database via FlexibleSearch and SQL statements.
Models
Models are a new way to represent Hybris items. Each model contains all item attributes from all extensions thus unifying access to an item's data. Models are generated from the type system of SAP Hybris Commerce. Furthermore they are more or less simple POJOs (Plain Old Java Objects) that can be used without any storage facility. Thus, it's pretty easy to mock them up, for example for testing and debugging. Models are used by DAOs, services, strategies, converters, and facades.
