PEGA设计黄金十法则(翻译) ---- RoyZhang

PEGA Design Ten Guardrails

PEGA设计黄金十法则

这10条指导方针摘要了最重要的Pega设计要素。

1, 采用迭代的项目开发方式。

定义一个初始的能够在60-90天里交付使用并提供商业价值的项目范围。

好处：一个迭代的方式使你迅速将解决方案转化为生产环境，使你可以迅速获得来自业务的反馈并更新在接下来的版本中。

最重要的关键：

首先文档化5个具体的USE CASE场景，并在最后评估测量它们的业务价值。

用情节串联图板描述这些USE CASE场景，并确认每一个都能带来可测量的商业价值。

 

2, 建立一个强健的基础。

类结构的设计必需满足Rule层次的期望。

好处：因为是应用的基础，良好的类架构对优化流程和性能将起决定性作用。类架构必须是可理解的，易扩展的，并且适合构架标准Work和Data类的。

最重要的关键：

使用组织架构实体为开始式样，然后继续进行Class Group。

以Work Object为导向，创建类结构和尽早完成Work Object。

使用 Applies To class and/or RuleSet来正确放置rules。

灵活使用继承来防止创建冗余的Rules。

 

3, 不要把工作复杂化。

使用标准Out-of-the-box Rules和函数来初始化应用程序。不要重复开发系统已提供的功能。

好处：使事情简单化。使用内置已测试完备的组件来提升从项目到上线的速度，并使你的应用程序从将来PRPC后续版本中增强的功能里受益。

最重要的关键：

从标准Rules复制或继承来生成你自己的Harness和Section，并使用相同的目标名称。不要从草稿开始生成Work Object表单。仅使用标准按钮。

总是为Section Rules和Flow action rules检查自动生成功能。

总是从标准Rules，Work objects, Properties上开发。报表，Urgency，Work status，和其它内置行为依赖于标准Properties。

决不要建立一个属性去控制典型Work或者管理Work的状态和时间。

 

4, 限制Java硬编码。

当有相同的标准Rule类型，库功能，或者Activity函数存在的时候，避免使用Java步骤在Activities里面。

好处：虽然直接使用Java功能强大，但在Activity里面使用Java步骤或者在HTML rule里面使用前请先调查所有已存在Rules和标准Rules。

最重要的关键：

保留你宝贵的时间和Java技能来实现系统还没有的功能。

使用更多但是更简单的Rules来促进累计性和可重用性来增强维护能力。

 

5, 为变而生。

识别和定义10到100条独立的Rules可以让业务人员拥有和维护。

好处：由业务用户通过Smartbuild流程打开discuss rules。他们对这些Rules负责。当应用程序发布以后，将这些Rules代理给相关的业务个体和组。

最重要的关键：

不要将Activities暴露给业务人员，使用其它的Rule类型给业务人员维护逻辑。

 

6, 设计目标驱动流程。

你的应用程序控制结构必须由流程Rules和Declarative Rules组成，只有在需要的时候才调用activities。

好处：目标驱动的流程使用规则驱动智能来引导用户在给出的情形下做对的事情。

最重要的关键：

使用Flower Action来提示用户输入。

不要为独立的Assignment表现超过5个Connector flow action。如果有需求需要超过5个，确认每个Action都是目标驱动的流程的一部分Assignment。

为了最大化可重用性，创建Activities来实现单一功能。

记住即使是单独的数据更新可能是一个小的流程。

 

7, 创建简单易读的流程。

你的流程必须在一页里完成并且不要使用超过15个流程图形（不算路由图形，Notify图形和连接线）每页。

好处：流程必须简单易读，从上至下，从左至右，尽量不要在步骤间互相交叉。

最重要的关键当流程超过15个图形的时候：

创建子流程和Call，Branch或者Spin-off来调用它。

使用并行的Flow和Split/Join或者Split-for-Each图形。

 

8, 有规律的监控性能。

至少每周一次使用性能工具评估或调试应用程序性能来检查效率。

好处：总是在开发的时候分配时间来进行系统性能测试来保证你的应用程序运行是干净而有效的。

最重要的关键：

使用性能工具来捕获内存和处理器以及输入输出需求量的细节状态。

使用系统控制台Servlet来监控后台进程。

 

9, 计算并编辑Declaratively，不要过程化。

只要可能就使用declarative规则来计算或者验证有效的属性值。

好处：Declarative规则是即变即知的，并且替代了更耗费的用activities来检查和实现属性值变化的方式。

比如：

在一个Activity里创建一个Declare Expression rule代替使用一个Property-Set函数。

使用Declare Constraints Rule来代替Validation Rule。

 

10, 保持面向对象的安全性设计。

你的安全性设计关于谁能访问哪个类型的Work也必须基于rule和基于角色驱动。

好处：标准Rule types(Access Roles, Access Whens, Privileges and Settings) 提供了控制谁可以访问各部分Work对象的能力。使用这些Rules来为你的基于Class的解决方案实现可升级的安全模式。

最重要的关键当流程超过15个图形的时候：

不要使用Activities和函数来检查安全限制。使用安全相关Rules将在所有时候检查安全限制。

从使用标准控制角色开始。

使用Rulesets and Ruleset Versions来管理Rule在业务中的变化，而不要作为一种安全度量的方式。