Page History

...

As  at the moment an aggregate definition can contain only singletons, the design of the aggregate Person only consists of entities Person and CurrentEmployment. However, the entity Person has relations with the non-singleton entities Job and Household, so whenever a person is stored, his or her jobs are also stored, as well as the person's household situation.

When storing such an aggregate, metadata is stored as well. This includes standard metadata, such as when the aggregate has been created and who created it, but also custom metadata that the business engineer can define on the aggregate definition by using expressions. This custom metadata are identifying attributes for an aggregate. In the example above, the Person aggregate could have the following custom metadata attributes: FirstName,LastName, SSN, CurrentJob, HouseholdSize. As you see, custom metadata for an aggregate can originate from different entities, or even be a complex expressions, for example NumberOfJobs is calculated as COLLECT ALL Job FROM Person.HasJobs.

Only the (custom) metadata is available in lists, as this information is stored in an efficient manner. When a new aggregate entry is created or updated, the (custom) meta is updated.

Working with aggregates

In order for an end user to work with aggregates in cases, it must be possible that these aggregates are displayed in a list. This list functionality is very similar to the list functionality that is already available for instances, tasks and cases and is implemented as a Blueriq container.

...

References between aggregates

Authorization

Migration