業務中是否寫了大量的 if-else？是否受夠了這些 if-else 還要經常變動？ 業務中是否做了大量抽象，發現新的業務場景還是用不上？ 是否各種調研規則引擎，發現不是太重就是接入或維護太麻煩，最後發現還是不如寫死？ 接下來給大家介紹一款全新的開源規則引擎——ice.
ICE的使用者:
簡單體驗
我配置了三個疊加測試的規則
Ice中有三種葉子節點類型，對應三種業務抽象
- *Flow 用于能控制業務流轉的抽象，如各種判斷或過濾條件，有明确的true和false傳回
- *Result 用于一些結果的抽象，如發放各種獎勵，有較為明确的true和false傳回(如在獎勵發放中，發了應該傳回true，沒發應該傳回false)
- *None 用于一些無關業務流轉的抽象，如查詢資訊，無傳回值
節點開發過程中，選用自己需要的抽象葉子節點繼承并實作對應方法即可。
- BaseLeaf* 使用IceContext作為方法入參，需要實作do*方法
- BaseLeafPack* 使用IcePack作為方法入參，需要實作doPack*方法
- BaseLeafRoam* 使用IceRoam作為方法入參，需要實作doRoam*方法
關系節點為了控制業務流轉
AND
所有子節點中，有一個傳回false 該節點也将是false，全部是true才是true，在執行到false的地方終止執行，類似于Java的&&
ANY
所有子節點中，有一個傳回true 該節點也将是true，全部false則false，在執行到true的地方終止執行，類似于Java的||
ALL
所有子節點都會執行，有任意一個傳回true該節點也是true，沒有true有一個節點是false則false，沒有true也沒有false則傳回none，所有子節點執行完畢終止
NONE
所有子節點都會執行，無論子節點傳回什麼，都傳回none
TRUE
所有子節點都會執行，無論子節點傳回什麼，都傳回true，沒有子節點也傳回true(其他沒有子節點傳回none)
葉子節點為真正處理的節點
Flow
一些條件與規則節點，如例子中的ScoreFlow
Result
一些結果性質的節點，如例子中的AmountResult，PointResult
None
一些不幹預流程的動作，如裝配工作等，如下文會介紹到的TimeChangeNone
flow的DEMO
import com.ice.core.context.IceRoam;
import com.ice.core.leaf.roam.BaseLeafRoamFlow;
import lombok.Data;
import lombok.EqualsAndHashCode;
/**
* @author waitmoon
* 取出roam中的值比較大小
*/
@Data
@EqualsAndHashCode(callSuper = true)
public class ScoreFlow extends BaseLeafRoamFlow {
private double score;
private String key;
/*
* 葉子節點流程處理
*
* @param roam 傳遞roam
*/
@Override
protected boolean doRoamFlow(IceRoam roam) {
Object value = roam.getMulti(key);
if (value == null) {
return false;
}
double valueScore = Double.parseDouble(value.toString());
return !(valueScore < score);
}
} 場景感受
我們假設一個場景,有一個老鐵要來貸款,可是貸款産品有一些硬性的要求,最簡單的是全是AND關系,給以産品配置上如下規則(配置的Flow,如果都為True,則Result傳回一個ID)
和
當我們傳入參數,參數都是動态設定的,隻要建立好規則,完全不需要改動代碼!
後續傳入age即可!
編排思想
全新的編排思想，在保障解耦和複用的同時，提供了更大的配置自由度，極大的降低了規則維護成本。
性能卓越
幾乎不消耗任何性能，隻需關注業務自身性能。
接入簡單
簡單的學習成本，幾分鐘就能上手編排，開發配置與抽象成本低。
#挑戰30天在頭條寫日記#