Overview
In a spring application, we usually have three layers and each layer have a different responsibility.
- Web Layer (Controller, Exception handler, Mappers) - receive the request and send the response to the client.
- Service Layer - Business logic
- Repository Layer (Repository Interfaces & custom Repositories) - DB interaction at the lowest level
CPS have four layers of architecture and the 'Persistence Layer' was introduced to have loose coupling with DB. It gives an ability to move to another type of DB with little change.
The current implementation for the persistence service SPI is provided in 'cps-ri' which is specific to relational DB. If we want to use another type of DB later, the Persistence and Repository layer needs to be re-written. To achieve the original intent (use a different DB type later), it is important to keep the business logic in the 'Service' layer and have only database-specific logic in the 'Persistence' layer.
Proposed Refactoring
CPS-core has three Services (Admin, Module & Data) and each is responsible for actions on the domain objects in CPS.
| ServiceName | Domain Objects | Supported Operation |
|---|---|---|
| CPSAdminService | Dataspace and Anchor | Create, Delete & Read |
| CPSModuleService | Schema-Set | Create, Delete & Read |
| CPSDataService | DataNode | Create, Delete & Read & Update |
In the existing implementation, the 'Admin Service' and 'Module Service' have the implementation to delete Data Node which is managed by 'Data Service'. This behaviour is not expected as 'Data Service' is responsible for deleting DataNode and should control how it can be done. The other services should utilize this functionality from DataService wherever required.
As a part of this proposal, the business logic