Refactoring to move business logic to Service Layer

CPS-791: CPS-Core sends DELETE notification eventClosedOverview

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 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 of 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. Therefore, 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

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.

In this proposal, the business logic of the 'Delete SchemaSet' and 'Delete Anchor' functionality will be moved to Service Layer and domain-specific services will be used to do any operation of the domain objects.

Delete Anchor

When an anchor gets deleted, all the associated data nodes should get deleted too. The suggestion is to use DataService to delete the data nodes instead of using Fragment Repository directly.

Delete Schema Set

Schemaset contains the model against which the anchor data nodes are validated. So, when a schema set is deleted, the logic to validate if associated anchors exist and whether it can be deleted is business logic and should be in the Service layer.

Delete SchemaSet Business Logic

DELETE SCHEMASET( dataspaceName, schemaSetName, cascadedAllowed)
      anchors = CALL Get Anchors associated with Schema Set ( dataspaceName, SchemaSetName )
	  IF Cascade is Prohibited & anchors exists
 			throw exception
      END IF
	  Delete associated anchors if casacade allowed
	  Delete SchemaSet
END