Page History
...
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 definition of 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. This principle can be extended to multiple levels deep, so if a Job would have a relation to yet another entity, instances of that entity in this relation would also be stored. See also Aggregate design.
...
As shown in the aggregate list in the previous section, 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, it will result in an new entry with increased version number. When reading an aggregate, a specific version can be specified. This means that it is possible to load an older version of an aggregate into the profile. One can also decide to just alter the latest version without creating a new version. The same goes for deleting an aggregate, you can choose to delete an aggregate with all its versions, or only a specific version. 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:
...
In any field of design - be it art, industry or IT - there's always the question whether a design should be made top - down or bottum up. In top down modeling, the starting point is the complete solution, which is broken down in a few iterations into smaller elements, whereas bottom up design starts wiht with creating all building blocks, which are then assembled to in iterations and then result in the intended solution.
Historically, Blueriq is a product that is very suitable for bottom up design, but top down is also possible. When modeling in the field of dynamic case management and using aggregates, a top down approach suits better than a bottom up approach. This will be discussed here.
|
Top down design
Designing Blueriq applications top down means that at first, (amongst others) cases and registrations are identified. A Both a registration as well as a case can be seen as an aggregate, so designing aggregates is easy. Domain design : for each identified case and each identified registration, an aggregate can be declared. In some situations, registrations are not native, so a web service might suit better than an aggregate. The final step, designing the domain is also not that difficult: we just have to design fill up the aggregates, which means deciding which entities are part of which aggregate.
See the right side of the diagram below above to illustrate the top down design.
...
Designing an application bottom up starts with meticulously designing the domain, with all its entities and relations. When designing aggregates, these some relations need to be excluded from the aggregate design, otherwise the aggregates contain too much data. After designing the aggregates, a separate design has to be made which contains the intended application. 
See the left side of the diagram above to illustrate the top down design.
| UI Text Box | ||
|---|---|---|
| ||
| Although both design strategies (top down and bottom up) are supported by Blueriq, designing a DCM (dynamic case management) solution is preferably done top down. |
References between aggregates
...
Overview
Content Tools