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.