Page History
...
Organizations usually offer more than one product or service to their customers. All these products and services have their own cases, so multiple cases can be running concerning the same customer. To get a good overview of a customer there is a need for shared storage of information, which is shared among the several cases. To accomplish this, the concept aggregate is introduce in Blueriq. See the example below.
Shown above are three different cases (in grey) that are all part of a single business model of a fictitious insurance company. The first case concerns a medical insurance, the second a dental insurance and the third a home insurance. These cases use and share information (in blue). The medical and dental case both use the medical information and information about persons, whereas the home insurance makes use of the person information and information about houses. These information objects are called aggregates in Blueriq and will typically exist of one or more entities with their endogenous 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.
Since it suffices to declare the main entities in a domain model that are to be part of the aggregate, the design of the aggregate Person only consists of the entities Person and Employment. However, the entity Person has relations with the 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.
...
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.
 |
|---|
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.
...
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, which can all be modeled in Blueriq:
- No versioning
With this strategy each create action will result in a new aggregate instance. Updating an aggregate instance means overwriting the original aggregate instance and deleting an aggregate instance will actually delete the aggregate instance from the database. Reading a non-versioned aggregate instance is trivial: Full versioning:it will read "the" aggregate instance, since there is only one. - Versioning all
With this strategy each create action will result in a new aggregate instance as well, but updating an aggregate instance means that a new version of the instance is stored alongside all previous versions. When deleting such a versioned aggregate instance, it is necessary to specifiy which specific version(s) to delete. Reading an aggregate instance also means that it has to be specified which specific version(s) to read.
Beware that the number of versions for an aggregate instance can grow out of control with this strategy. Also, think about the design of your aggregate list when using full versioning. - Versioning latest
This strategy is based on the previous strategy, but with some limitations for the end user. Versioning is still in place, so updating an aggregate instance will create a new version of the instance, but in this strategy reading will always return the latest aggregate instance version. Deleting an aggregate instance with this strategy means deleting all versions. Also be aware of the fact that the number of versions for an aggregate instance can grow out of control.
References between aggregates
...
Overview
Content Tools