Versions Compared

Key

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

...

Note

Please think carefully about the choices for your metadata attributes. If you at a later point in time want to add a different metadata attribute, it will be empty for all existing aggregate entries. Once such an existing entry is updated, the new metadata field is going to be filled.

 

Working with aggregates

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 similar to the list functionality that is already available for instances, tasks and cases and is implemented as a Blueriq container.

...

  • No versioning
    Updating an aggregate instance means that the original aggregate instance is overwritten. There is always one single version of the aggregate in the database present. Reading a non-versioned aggregate instance is trivial: it will read "the" aggregate instance, since there is only one. You should use this strategy if the past state of the aggregate is not important.
  • Versioning all
    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 specify 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. You should use this strategy if it is important what the state of the aggregate in the past was. For example the employment status of a customer at the moment of the start of the application. Any changes during the processing of the application should not be considered.
  • 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. You should use this strategy if you always want to work with the latest version, but you still want to keep a history of the aggregate. A good example is the address of a customer. You always want to use the newest address for correspondence, but keeping the old addresses may be useful. 
Info

These strategies are not enforced, and it is up to the Business Engineer to choose one and follow it during modeling. The Business Engineer has all the freedom to choose the correct action for every situation.

...

References between aggregates

...