Versions Compared

Old Version 26

changes.mady.by.user Menno Gülpers

Saved on

compared with

New Version 27

changes.mady.by.user Menno Gülpers

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Aggregates are used to combine information that belongs together, and should be stored and loaded together. In Blueriq, information that belongs together is modeled in an entity, or as multiple entities with relations between them. An Aggregate is the selection of parts of your domain that can be stored and retrieved together in a single action, and consists of one or more entities. When a singleton an entity is added to an aggregate definition, all non-singleton entities that are connected to the singleton entity are part of the aggregate as well. At the moment it is not possible to create a precise aggregate definition, excluding for instance a few attributes and relations.

Shown below is the design of the aggregate Person information, in which the aggregate is blue, and the entities that are defined within the aggregate are pink.

Image RemovedImage Added

Since it suffices to declare the singletons main entities in a domain model that are to baprt be part of the aggregate, the design of the aggregate Person only consists of the entities Person and CurrentEmploymentEmployment. 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. See also Aggregate design.

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 can be seen as identifying attributes for an aggregate, but are not necessarily unique. In the example above, the Person aggregate could have the following custom metadata attributes: FirstName, LastName, SocialSecurityNumber, 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 Job FROM Person.HasJobs. It is even possible to define custom metadata that does not originate from entities of the aggregate definition at all, since custom metadata consists of an expression.

...

To let the business engineer create meaningful aggregate lists, custom metadata attributes can be added to the aggregate definition and then used as column in the aggregate list. Below is an example of such a list, which illustrates sorting, filtering, custom metadata and paging. For more information on the aggregate list see AQ_Aggregate_List.

Image Added

By letting the business engineer create different aggregate lists for different purposes, the end user will work with only the aggregates that are relevant for him. Since only metadata from these aggregates is retrieved from the database while displaying them - and not all data completely - this will boost performance.

Aggregates can be created, read, updated and deleted. For these specific actions, services are available in Blueriq.

Versioning

As shown in the aggregate list in the previous chapter, it is possible to specify versioning for aggregates. This means that when creating an aggregate, a version number is stored along with it. When updating an aggregate, the version to update has to be specified and the update itself will result in an increased version number. When reading an aggregate, a specific version can be specified. The same goes for deleting an aggregate. It is advised to use a control entity to store the aggregate IDs as well as the version IDs.

There are three versioning strategies when designing aggregates:

  • No versioning:
  • Full versioning:

References between aggregates

...

For metadata the same principles hold as for domain attributes. A special case is a change in the expression of a custom metadata attribute. Here also the lazy principles applies. When the expression for a custom metadata field changes, the value in the database is updated the next time an update action is performed for the aggregate entry.

See also

More about aggregates can be found here:

...