Page History

...

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 could enable the knowledge worker to look for a known person in the system if this person contacts the call center. 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.

To let the business engineer create meaningful aggregate lists, custom metadata attributes can be added to the aggregate definition. A custom metadata attribute is an attribute that is not necessarily part of the domain and is therefore defined by an expression. This expression may however only use relations and attributes that are directly or indirectly part of the aggregate definition. In the example above, an aggregate list could contain custom metadata attributes like name, age, city of work or total number of persons in the household. The aggregate list cannot contain a custom metadata attribute blood type, since this is part of the medical information aggregate and not the person aggregate.

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 a specific set of data metadata from these aggregates is retrieved from the database while displaying them - and not all aggregates data completely all the time - this will boost performance. In case of a relatively small amount of data, it is possible to store and read all information all the time and display all aggregates in a single list. However, this approach is not scalable and therefore not advised.

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

References between aggregates

In many situations you want that different aggregate entries refer to another. For example should the case aggregate refer to the person that this case is about.

You should model an attribute at the case entity which stores the aggregate Id of the Person aggregate. When loading the case into memory, first the case aggregate is loaded. This retrieves the person aggregate Id, which can be loaded afterwards by a second service. When initially creating the aggregates the order has to be reversed. For updating, the ordering does not matter, as the Id does not change.

Authorization

There currently is no authorization on aggregate level. This means that you are responsible for prohibiting the end user to load certain aggregates by chosing adequate authorization on page or container level.

Migration

When your application changes over time, the migration of data becomes an important topic. Aggregates help you with this, but can not solve all your problems.They generally do everything in a lazy manner, so that not the complete database is updating when the server starts.

A new attribute is added

When a new attribute is added to the domain, all already stored attributes do not have this attribute. In this situation, it is possible to load existing attributes, and the value is simply set to unknown.

An attribute is deleted

When loading an existing aggregate that still has this attribute, then this attribute is ignored. Upon the next update action, the old entry is overwritten and the information of the deleted attribute lost.

An attribute is renamed

Renaming an attribute is regarded as deleting the old attribute and adding a new one. Existing information is the old attribute is lost.

Metadata

For metadata the same principles hold as for domain attributes. A special case is the changing of 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.