I'll be back!

一個強壯的prpc系統很關鍵的一點就是看代碼的重用性，為了滿足特定需求且僅滿足該需求的功能模塊是脆弱的，必須在設計之初就必須充分考慮到需求的變更，最大幅度擴大該模塊的運用場景。
以創建組織地點下拉選擇框(選擇地域信息)為例子，脆弱的做法就是直接在property內對下拉選擇框的值進行配置(Name, Value)。而一個好的做法就是創建一套對應的field value。 當然這個例子并不適用于那些特定模塊的下拉選擇框，
再舉一個例子，我們在制作一個篩選用戶的html property的時候，好的設計應該把篩選用戶的條件作為parameter設在里面，例如OrgFilter, DivFilter,UntFilter,LocFilter等等。
如果項目在提交到客戶之前就本項進行"Health"檢測的話，可以讓BA在原來的BRD基礎上進行一定幅度合理的變更，然后有開發人員評估系統變更所需要的開發時間，由此來判斷該系統代碼是否擁有足夠的靈活性(當然這個評判標準是一個經驗值)。

我覺得題目開的很宏大，支持一下！！
但真正要提出一個標準來，是有相當的經驗來作基礎，并且要經過很多驗證。我們可以從小的地方開始作：分享一些怎么作可以使prpc application 更加健康的case。
這樣一來可以積累很多人的經驗，二來可以使我們分享這些經驗當工作中遇到問題時提供借鑒。

這個題目很好,不過就算是Pega公司本身也很難給一個滿意的答復。
個人感覺，PRPC的開發不適合規模型的外包開發，只適合緊湊的精英型開發。而所謂開發，其實大部分的工作就是在分析和設計，而實際的代碼工作量不會多到哪里去；相反一個系統如果沒有很好的規劃和設計而匆忙開發，那么最終的結果將是很鬧心的。

如果長期規模化以及低素質的開發人員維持低效的開發，有可能最終產生大量的rule，這些rule的特點往往是高度冗余，通用性差，難以統一維護。
PRPC目前的一個很大問題就是對十萬數量級以上的rule management很差。到這種程度上ruleset這個東西就顯得很力不從心了。
所以我同意樓上的觀點。