Description

To get this project working, the aggregate plugins and properties need to be set correctly. See for installation details this page.

This example project aims to demonstrate the functionality regarding persistency management. The following subjects play a role in this example project:

• Aggregate design (see also Aggregate (Studio))
• Singleton versus non-singleton
• Custom metadata
• Versioning
• Displaying aggregates in a list (see also Container type: AQ_Aggregate_List)
• Creating an aggregate (see also Service call type: AQ_Aggregate_Create)
• Reading an aggregate (see also Service call type: AQ_Aggregate_Read)
• Updating an aggregate (see also Service call type: AQ_Aggregate_Update)
• Deleting an aggregate (see also Service call type: AQ_Aggregate_Delete)
• Searching for an aggregate (see also Service call type: AQ_Aggregate_Search)

...

The example project consists of two parts. The first part is about a single person and his jobs. The second part is deals with a non-singleton entity Course.

Contents of the example project

...

The course group aggregate only consist of the entity Course, which is a non-singleton. The create service for the aggregate CourseGroup is defined in such a way, that it is possible to save more than one course in such an aggregate. An exposed flow CourseGroupManagement is available to manage course group aggregates, as shown below.

Image Modified

A course has a duration in number of days and a price in euros. Custom metadata fields have been defined within the course group aggregate to summarize the number of days and the price and count the number of courses for each course group aggregate. Versioning has been disabled in this part of the example, so only the latest version of each aggregate is available.