Page History

...

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. At the moment, only singleton entities can be When a singleton entity is added to an aggregate definition, but all non-singleton entities that are connected to the singleton are part of the aggregate as well. Also, at 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.

Since at the moment an aggregate definition can only contain singletonsit suffices to declare the singletons in a domain model that are to baprt of the aggregate, the design of the aggregate Person only consists of the 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 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 ALLJob 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.

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) metadata is updated as well.

...

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.