Guidance on Class Group Design – Separate Class Groups vs. Extending Common Class Group

Blueprint and App Design
1

We are building a Pega application on top of Pega Sales Automation and following a modular design approach. As part of this, we plan to separate Customer and Product into standalone applications so they can be reused across multiple upcoming projects.

We are evaluating two different design approaches for handling Customer and Prospect case types, and would like your input on which is the better option in terms of scalability, reuse, maintainability, and alignment with Pega best practices.

Approach 1 – Creating Specific Class Groups for Customer and Prospect

Build a ORG-specific application on top of the existing Pega Common application.
Create separate case types for Customer and Prospect, each under its own class group
These class groups will point to the Common-LDM-Entity-Contact DB table (common_contact).

Approach 2 – Extending the Common-LDM-Entity-Contact Class Group

Create a New Application on top of the Pega Common application.
Extend the Common-LDM-Entity-Contact class group to define new Entity Class(e.g., Common-LDM-Entity-Contact-Customer/Prospect).
These classes will inherit the common data model from Common-LDM-Entity.

Question:
Which approach is more suitable for our modular design strategy, especially considering future reuse of the Customer and Product components in other applications? Are there specific pros and cons or design guidelines we should be aware of.

2

Hi @Gaurav25, based on my experience I will opt option 2 to maximize the reuse of Pega data model to its fullest. I will try not to introduce new data models wherever possible and try sticking with Pega standard model until I have a very specific use case or requirement.

As you mentioned customer and prospect will be sitting in separate application which will be built on top of Pega Application extending Common-LDM-Entity-Contact class group in your layer.

3

That’s right. As Utkarsh mentioned, the advantages with approach 2 are: better reuse and flexibility to extend later, easy to manage reporting and reduces redundancy.

4

Hi @VijayVaddem, UtkarshS17501774 Thanks for the response, Pega SA is not recommending to use Common LDM and not building and application on top of that will not work for us.
Also from our current experience extending application on top of Common LDM is only beneficial if you are using the pega OOTB properties, however if you have need more attributes it better not built on top to Common LDM.