Unless there is a particular naming convention that the Pega ruleform suggests (Unit Test Cases should start with TC_) or mandates (Data Pages must start with D_), follow a principle of ensuring a rule is named in a manner that accurately describes its purpose in the application, without reflecting details about how the rule is implemented.

For example, if a When rule determines whether approval is required for an Expense claim, and the requirement is that claims valued more than $100 require approval, name the When rule IsApprovalRequired, not IsExpenseValueGreaterThan100. Inevitably, the approval criteria will evolve over time: the value threshold may change; or additional properties about the Expense Claim become part of the condition. 

• A rule named based on how it was first implemented can misrepresent its evolving implementation;
• A rule named based on what role is plays in the application is entitled to evolve its implementation, and is more reusable.

As for classes, use *-Data-* to represent classes that form the Logical Data Model of your client's applications. Ideally use a distinct class structure (e.g. *-Int-*) for Physical Data Model classes that differ from the Logical Data Model they serve.

Discussion on this topic was sought from the LSA Data Excellence (Pega 8.4) webinar conducted in July 2020. The webinar and its full set of discussions that arose from it are available at LSA Data Excellence: Webinar, Questions & Answers.