Question
Accenture
AU
Last activity: 18 May 2017 19:51 EDT
Best practice to using components
In the project I'm in, I've been tasked at looking into potentially "componetizing" organizational assets. I've read some PDN material on components, primarily here, but still unsure about its business case.
In the PDN example, it recommends saving the Credit Score calculation as a component so it may be used by 3 applications. It does not explain why this is a better data model to saving Credit Score in either the Organization or Framework layer.
Lastly, info on components seem to have stopped after PRPC 5. It appears to be largely absent from Pega 7 certification material. I was wondering whether the use of components has been deemed less relevant in favor of (as previously suggested) storing assets in the reusable layers of the Situational Layer Cake.
***Edited by moderaotr, Maryrita: moved to LSA from Applications***
Pegasystems Inc.
US
The problem with the idea for a ruleset being a component is that a ruleset does not satisfy the definition of a component.
Component is a recursive term. A component can be composed using other components. Objects can be composed from other objects. And finally Applications can be composed (built on) other Applications, especially since 7.2 when Pega began supporting multiple built-on Applications.
A ruleset however cannot be composed using other rulesets. You can merge rulesets but this is contrary to the fundamental princliple in software that problems are best solved using the Divide and Conquer principle. You can try to use decomposition to arrive at a component/object but what if the ideal solution requires more than one ruleset? Hence component Applications make more sense.
See also: micro-services