Designing case specialization and extensibility

The key requirement is implementing business logic specific to an entertainment venue when the need arises. There is no requirement that states different database tables must store each venue’s data.

There are three possible approaches for this solution:

1. Represent the differences between venues as data. Implement rules that can process this data.
2. Implement venue specialization within the current application.
3. Use the current application as a framework/model/template/blueprint. Create an implementation application for each venue.

Data-driven rules

In this approach, an attempt is made to model the differences between venues as either data instances or custom non-Pega rules that are treated as data. Rules are developed with the ability to react to this data regardless of the venue.

Single application rule specialization

The single application approach satisfies the current routing requirements leveraging the org structure. If only a few differences are anticipated between venues, circumstancing can suffice. For more complex differences, you can use pattern inheritance and utilize venue-specific classes that have been defined. Then, you can use Dynamic Class Reference (DCR) to decide which class to create.

Application per venue

The multiple application approach also satisfies the current routing requirements that leverage the org structure. An application is created for each venue. Case types within each venue-specific application extend a case type class within the current application. Venue-specific business logic differences are handled by saving the rule from the current application to the corresponding case type class in with the venue-specific application. Users must switch applications to create and manage cases for different venues.