1.產生背景
想到“通過什麼->得到什麼”類問題，第一個想到的恐怕就是活動類項目的開發，用戶通過一系列行爲，得到一系列的東西。但往往這類活動變動性較大，持續性較短，因爲活動玩法的不斷擴充與產品運營的腦洞不斷擴大，剛開始寫的一系列通用的規則往往付之一炬，久而久之，就只剩下一些相對獨立的抽象出來的基本模塊，然後再通過摞代碼方式將模塊組裝起來。
由於一個新活動往往與老玩法有關又無關的特性，新的活動也必須在開發，測試等環節上耗費較大精力，所出問題也比較多，以至於慢慢的，大家基本都認爲，做活動類項目，直接摞代碼就行，考慮複用性只會增加開發成本，且下個活動能夠全部複用上的概率不大。爲了找到一個簡單，易用的通用營銷引擎，曾調研過一系列的規則引擎等(如Activiti，Drools，Flowable)，但大多上手較難(Baikal可能也不簡單)。
本人也是深受活動類項目迫害，以至於覺得做活動完全就是一個磨性子的工作。
有迫害就有反抗，於是，Baikal歷經三年多在幾經周折與不斷變更的情況下誕生了，Baikal項目核心框架目前已經基本開發完畢，也在實際場景中發揮了舉足輕重的作用。
Baikal只是提供了一種此類問題的解決方案，並不敢說最優，只能說你可能會有所借鑑。
2.Baikal簡介
eg:某商場想舉辦一個女神節活動，規定
1.活動期間女生用戶/擁有商場會員卡的用戶可參加活動
2.女性並且擁有商場會員卡的用戶，可享受滿100元返現50元/滿50元返現20元的活動
3.能夠參加活動的用戶每人贈送1支鮮花
4.商場常年活動:不論是否能參加活動，消費滿10000元贈送1個珍藏版商場吉祥物
現在你有:
1個只會通過身份證校驗是否是女性用戶的員工A
1個只會校驗是否有商場會員卡的員工B(但是要報手機號等操作，校驗工作比較慢)
3個只會校驗消費金額的員工(一個校驗100元C 一個校驗50元D 一個校驗10000元E)
1個只會送錢的員工F(需要被告知送多少 傳遞告知-上下文)
1個只會送花的員工G(需要被告知送多少 提前告知-配置)
1個只會送吉祥物的員工H(需要被告知送多少 提前告知-配置)
和若干能夠了解活動規則，但除了指導用戶怎麼走，什麼都不會的匿名員工
如果是你，要怎麼安排？
其實上述所述的員工，就是對一個活動的拆解，做到單一目的的員工，如果下次出現了新活動，需要送吉祥物，直接複用那個會送吉祥物的員工即可，功能足夠單一，但是要怎麼拼接起來，保證活動的順利進行呢？
先解釋一下上圖：
1.所有的校驗員工，校驗符合則返回TRUE，不符合返回FALSE
2.所有的葉子節點都是會點東西的員工，這裏叫葉子節點
3.所有的擁有子節點的員工，這裏叫關係節點
關係節點的解釋：
1、And 所有子節點中，有一個返回FALSE 該節點也將是FALSE，全部是TRUE纔是TRUE，在執行到FALSE的地方終止執行，類似於Java的&&
2、Any 所有子節點中，有一個返回TRUE 該節點也將是TRUE，全部FALSE則FALSE，在執行到true的地方終止執行，類似於Java的||，Any用於result，Or用於flow
3、All 所有子節點都會執行，有任意一個返回TRUE該節點也是TRUE，沒有TRUE有一個節點是FALSE則FALSE，沒有TRUE也沒有FALSE則返回NONE，所有子節點執行完畢終止
4、None 所有子節點都會執行，無論子節點返回什麼，自己都返回NONE，任何沒有子節點的關係節點將自動返回NONE
5、True 所有子節點都會執行，無論子節點返回什麼，自己都返回TRUE，任何沒有子節點的關係節點將自動返回NONE
寫到這裏才發現寫的有點複雜，例子不是很好，尷尬，哈哈哈…
圖中實際上還有些操作可以簡化一些，比如8號節點發放的吉祥物獎勵，其實可以把7號節點做成一個前置節點，也就是7號必須通過纔會執行8號，這樣就不再需要3號節點的存在，簡化樹結構方便閱讀和理解。
變化後：
黃色框中的代表前置節點，只有前置節點通過(非FALSE)纔可以執行
3.Baikal能帶來什麼
1.業務拆解顆粒度可控
如果你現在有一個會校驗10000元並且會發吉祥物的員工，那麼3-7-8節點可以完全替換成這一個員工，但是顯而易見的，這樣的員工，下次複用的概率，也不會高，如果下次真的要複用，直接把已經形成大顆粒度的3-7-8號節點拿出去，就可以滿足。
2.可擴展性/更改更容易
如果此時，突然被告知，女神節活動只有女生能參加，不再需要和商場會員卡掛鉤的那一塊內容，那直接和11號節點脫鉤即可。
如果此時突然宣佈，能夠參加的女生必須是國內用戶，只需要在4號節點前增加一個判斷是否是國內用戶的節點即可，其他節點照舊，不受任何影響。
3.配置化更新
可以通過數據庫等，實現配置化更新
4.異常出現與恢復
如果此時7號節點突然異常，E員工突發身體不適，那麼可以把整棵樹和影響用戶的信息存儲起來，等到E恢復/更換員工後，在將異常數據從7號節點繼續執行後續。若此時商場臨時決定，給受影響用戶補發優惠券作爲補償，也爲特別處理提供了可能
備註
Baikal項目的設計思路已經介紹完畢，目前Baikal項目已經用於正式的生產並扛過了活動類項目嚴酷的考驗，也在不斷探討着其他應用場景，後續會持續優化，更新相關設計及實現細節。
有更好方案/簡易的小夥伴歡迎交流~~