Class Structures & Hierarchy Design

Class structure design is an integral part of every Pega application. Designing a scalable, extensible enterprise class structures from the beginning of your project will help avoid costly re-factoring. The enterprise class structure enables PRPC applications to co-exist with each other and with customer or Pega built frameworks.The enterprise class structure is also the foundation for enterprise reuse. Asset reuse is integral to the long-term success of BPM within the organization and ultimately, the reusability requirements drive the selection of your class hierarchy design.Careful planning and analysis are important before creating the new classes, to understand their interrelationships and plan their positions in the standard class hierarchy. Maximizing reuse of standard classes, standard properties, and other standard rules is a proven tactic for fast development at minimum effort.

PRPC Base Product Layer:The PRPC Base Product Layer consists of the Pega RuleSets and its classes & rules. Loaded as part of the PRPC platform install, this layer contains all rules necessary for workflow processing and other areas of Process Commander. While the Pega RuleSets are locked, rules that apply to many of the Pega classes (Work-, Embed-, Data-, @baseclass, etc.) can be defined in application RuleSets to support enterprise-wide reuse.

Enterprise Reuse and Divisional Reuse Organizational Layers:The Enterprise Reuse and Divisional Reuse Organizational Layers is where extensions to the work and data classes exist. This may include enterprise wide or division wide business logic (standard properties, flows, decision tables, models, SLA rules, etc.), data classes (such as generated class structures for connector request/response messages) as well as other extensions exist. The classes within the Divisional Reuse layer inherit from their counterparts in the Enterprise Reuse layer; the classes of the Enterprise Reuse layer inherit directly from the Work- and Data- classes.

Framework Layer:The Framework Layer stores base rules/processes/components for a given application. A customer built framework (CBF) serves as the basis for N number of deployments throughout the enterprise. A CBF must be able to stand on its own, therefore, this layer contains all rules necessary to implement its functionality. While there will be a class group and its mapping to a database table for testing purposes, the actual mapping of the application to production database table occurs on the Implementation layer. Organization specific logic, processes and rules must be placed on the Implementation layer as well, only default edits, values, and application structures have their home in the CBF layer.  This layer can also be used to extend any features present in a Pega based framework for a particular organization. In this case, there are one or more specialization layers on the Implementation level and the CBF and the Pega solution framework on the Framework level. The CBF has the Pega framework as its directed parent.

Implementation Layer:The Implementation layer contains the rules necessary to implement a Pega built framework or Customer Built Framework (CBF). This layer contains any specialization rules as well as the application class group(s) of the framework for the organization and division that it belongs to. The layer also contains flow shells and/or service activities used to start their generalized counterparts in the Framework layer.The EAA now creates an Enterprise Class Structure consisting of a CBF on the Framework layer and organizational implementationclasses on the Implementation layer