Designing case specialization and extensibility
3 タスク
１時間
シナリオ
MDC is expanding its service portfolio to include both home and office moving services for individual and business customers. A dedicated truck and driver will be assigned to each moving request, with pricing models and delivery tracking tailored to each service type and customer segment. As the Lead System Architect, your task is to evaluate the current Delivery Service application and determine the most appropriate architectural approach to accommodate these new requirements.
Your responsibilities are to:
- Analyze the key requirements to determine whether the current application design can support business-type-specific logic for both individual and business customers.
- Prepare a structured list of clarifying questions to present to the MDC stakeholders before finalizing the architectural decision.
- Recommend the most appropriate enterprise class structure for the application going forward.
The following table provides the credentials you need to log in to the Delivery Service application. However, this challenge is mainly meant for evaluating the design options, and there are no specific implementation tasks.
| Role | User name | Password |
|---|---|---|
| Admin | admin@deliveryservice | rules |
詳細なタスク
1 Identify design options
The core requirement is to implement business logic that is specific to the customer type (Business or Individual) when differentiated behavior arises. For example, distinct pricing Rules, Service-Level Agreement definitions, or delivery tracking workflows.
There are three primary architectural approaches to satisfying this requirement:
Data-driven Rules
In this approach, differences in customer type are modeled as data instances or custom non-Pega Rules treated as data, rather than as class-specific Rule overrides. Business logic reacts dynamically based on the type of service (delivery service or moving service) at run time.
Single application Rule specialization
The single application approach satisfies routing requirements that rely on the organizational structure. If only a few behavioral differences are anticipated between delivery and moving services, circumstancing can be used to specialize Rules without creating new classes. For more complex differentiation, pattern inheritance can be applied, using service-specific classes already defined in the application. Dynamic Class Reference (DCR) is then used at runtime to determine which class to instantiate.
Application for each service type
In the multiple applications approach, each service-specific application contains Case Types that extend a Case Type class from the base application. Manage service-specific business logic differences by saving the overriding Rule in the service-specific Application Layer, within service-specific Rulesets and classes. If users work across both services, they must switch applications to create and manage Cases for different services. Consider this usability impact when designing the solution.
2 Evaluate design options
Review the pros and cons for each design option in the following table:
| Design approach | Pros | Cons |
|---|---|---|
| Data-driven Rules |
|
|
| Single application Rule specialization |
|
|
| Application for each service type |
|
|
3 Recommend the best design option
The recommended approach depends on the data and governance requirements of MDC:
-
When data separation across services is mandatory
If each service type requires its own database, compliance boundary, or isolated deployment environment, create a separate application for each service type. Use Remote Case Types and application layering in Pega Platform to support this pattern effectively. -
When data can be shared and service differences are limited
Use a single application with Rule specialization. This approach improves simplicity, maintainability, and extensibility. Apply DCR for class selection, use direct inheritance instead of pattern inheritance, and configure Views for each Persona in the Constellation UI. These practices align with Pega Platform architectural standards.