Versions Compared

Key

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

...

In the aggregate definition, relations are automatically followed and all entities that are connected to the entity by means of relations are automatically part of the aggregate, as well as all relations between these entities. The relations can be excluded from the aggregate definition, which means also entities connected to that relation are excluded. Relations cannot exist between aggregates, only within them.

warning
Note
UI Text Box
typewarning

Only the To-relations are followed automatically, not the backward (reverse) relations.

UI Text Box
type
Note

Abstract entities cannot be added to an aggregate.

Shown below is the aggregate definition of an aggregate PersonAggregate. The definition only contains the entity Person, but in fact all Jobs that this Person has are part of the aggregate as well. Instances of the relation HasJobs are used and stored as a connector between the instance Person and the instances of Job.

...

Where an entity divides the main model into main ‘subjects’, an aggregate groups some of these main subjects together into a coherent set. These entities can be added using the +Add entity button. Remove unwanted relations (and connected entities) from the aggregate definition using the toggle. The list of included relations is updated after each toggle update.

...

type
Info

Please note that any relations to instances that do not belong to the aggregate are cleared, and are not recreated when loading the aggregates.

...

Custom metadata can not be used in the same way that attributes can be used. This custom metadata can be seen as identifying attributes for an aggregate, but are not necessarily unique. The Person aggregate could have the following custom metadata attributes: FullNameAge. Custom metadata for an aggregate can originate from different entities, or even be a complex expression, for example NumberOfJobs is calculated as SIZE(Person.HasJobs).

note
UI Text Box
type
Info

You may be tempted to add as much metadata to an aggregate as possible, as these can be shown in lists later on. We strongly advice against adding metadata only for 'just in case'. Each metadata attribute creates an entry in the database when an aggregate is stored. The more metadata fields are added, the quicker entries are made in the database which at some point may impair the performance. Therefore, we advise the following:

  • Only add metadata if this really describes meta information of the information stored in the aggregate.
  • Try to not add more than 10 metadata fields per aggregate
  • Plan and execute performance tests with large database fillings before bringing your application to production.

Please see Runtime performance reports for how we test the performance of our reference application.

...