When to use a data structure in the backend?

The DS classes are complex datatypes used in resource classes except the ShipmentTaskDS. The ShipmentTaskDS is used as a carrier for data from camunda to the rest endpoint which is confusing because it has the same package and name but is used differently. Maybe it would be better to transfer data from camunda directly into a TaskResource instead in a ShipmentTaskDS and one method later into a TaskResource.

Right now, only cargos, services and shipments are saved in the database. But there are more data structs (cargo, enabled tasks, party, services and shipment tasks). Do we need for every resource a data structure or only for those classes we want to save in the data base?

Do we need the data structures at all?

As said in the first question the DS are the complex datatypes for resources. It was introduced to reduce the amount of variabled in the ShipmentResource.

For what do we need the data structures? If we want to save a shipment we do it in the REST-Method right now. We only use the data structures and resources to convert them between the controller and the services implementation.

What is the difference between SaveShipmentResource and ShipmentResource?

The difference is, that the SaveResource is just carrieng UUIDs of Customer because the frontend does not know the full data to that point. The question is, if it would not be possible to use the already existing ShipmentResource for saving shipments with empty fields for name, adress and so on.

Do we really need 2 resources to save the same data? There is only a marginal diffrence between those 2 classes.

Why are active tasks called shipment tasks in the backend?

Shouldn´t they be named active tasks, since every task is assigned to a shipment?

in the ShipmentBoundaryServiceImpl the return value is sometimes a shipment and sometime a shipment resource. But shouldn´t it be a ShipmentDS?

The return value is always a shipmentResource on a get (findAll or getShipment) method and a shipment on a post or put (updateShipment or createShipment) method. It should not be a ShipmentDS but for a clear boundary maybe every method should should return the resource OR the JPA object.

Anyway, the findAll method int ShipmentBoundaryService returns a Collection and the findAllActive method in ShipmentTaskBoundaryService returns a List which could be adjusted. 

In the ShipmentTaskBoundaryServiceImpl the return value is always a data structure. In the ShipmentBoundaryServiceImp the return value is sometimes a shipment and sometimes a shipment resource. (For example shipments() and getShipment() )

Is it necessary to write behind each method that documents a REST-Method the suffix be documentation?

Right now each method that documents a REST-Method has the suffix test. But is it really a test? And since it documents something, shouldn´t that be in the name instead of test?

What should the name for a documentation method be? Is it the name of the REST-Method with a suffix (e.g. createShipment and createShipmentTest / createShipmentDocumentation) or should the name reflect the content of the method (e.g. shipments and listShipmentTest)

If it is the method name with a suffix, the name of the method should be more precise and reflect what the method is doing

When do we need to use effects and when should we use the reducer?