Data model reuse layers

Designing a data model for reuse is one of the most critical areas in any software project. A well-designed data model has a synergistic effect, the whole being greater than the sum of its parts. In contrast, a poorly designed data model has a negative effect on the quality and maintainability of an application.

A temptation exists after a case type is created to immediately define its life cycle. Case life cycles can be rapidly developed in APP Studio with views that contain numerous properties, everything defined at the case level. This approach will become counter-productive at some point owing to the lack of reusable data classes and work pool-level properties that can be shared with other cases. Numerous hours would then be required to refactor and retest the code.

It is better to start out grouping related properties using Data classes, classes that would contain the views to display those properties. This is, after all, why an embedded page is now referred to as a “field group”. Creating Data classes promotes reuse across an application’s case types. Data classes enhance and simplify application maintenance.

It could be said that one of the primary purposes of a case is to manage a specific set of data. Managing data is a different role than being the data. Viewed another way, the primary purpose of data is to be used by one or more cases.

Cases have two types of properties:

It is rarely necessary to define new properties for the second type.

In certain scenarios you may be tempted to define a case type with little or no life cycle or behavior, with the intention to use the case type primarily to store data locally. The case life cycle might consist of changing pyStatusWork from New to Open to Resolved-Completed. It could have a single assignment with an SLA.

A case may appear simple at first and not worth having a field group. A build-for-change best practice, though, is to always associate at least one field group with a case type, one of the field groups being synonymous with the case type.

Some data is referenced or calculated, while other data is enhanced. The former is read-only, the latter is updatable.

For example, A Data-Warranty instance that contains static information such as the terms and conditions of a product’s warranty would be viewed read-only. A Data-Warranty-Claim instance, on the other hand, would contain dynamically varying properties such as PurchaseDate, ClaimDate, ExpirationDate, and Expired. Within the view that displays those additional properties, the first two would be updateable, while second two would be calculated, and hence read-only.

The sample Event Booking application also follows this pattern. The fields within an FSG-Data-Hotel instance are static from a Event case’s perspective. In contrast, the fields within a RoomsRequest instance are dynamic.

The data model for a case should also take into consideration the ease with which customer data is propagated from one case to another. A field group can be populated immediately prior to a subcase or spin off case being created. A field group used this way at a minimum would need to be defined at the work pool class level. If the subcase or spin-off case was an extension of a case type component, the applies-to class for the field group would need to be more generic, for example Work-Cover-.