Page History
...
| UI Text Box | ||
|---|---|---|
| ||
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. |
Design considerations
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 all building blocks, which are assembled to 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 top down means that first, cases and registrations are identified. A registration as well as a case can be seen as an aggregate, so designing aggregates is easy. Domain design is also not that difficult: we just have to design which entities are part of which aggregate.
See the right side of the diagram below to illustrate the top down design.
Bottum up design
Designing an application bottom up starts with meticulously designing the domain, with all its entities and relations. When designing aggregates, these relations need to be excluded from the aggregate design, otherwise the aggregates contain too much data.
References between aggregates
...
| UI Text Box | ||
|---|---|---|
| ||
| We assume that there is no relation between the case entity and the Person entity as the , since Person would be stored together with the case if and this is the casenot wanted. |
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.
...
Overview
Content Tools