桔妹導(dǎo)讀： LogicFlow 脫胎于滴滴技術(shù)團(tuán)隊(duì)在客服業(yè)務(wù)下的實(shí)踐，是由滴滴智能中臺(tái)體驗(yàn)平臺(tái)研發(fā)的一款流程可視化的前端框架，提供了一系列流程圖交互、編輯所必需的功能和靈活的節(jié)點(diǎn)自定義、插件等拓展能力，方便我們快速在業(yè)務(wù)系統(tǒng)內(nèi)滿足類流程圖編輯器的需求。 目前，LogicFlow 已經(jīng)在公司內(nèi)外不同用戶的流程配置需求中得到了驗(yàn)證。

1. 

背景

首先，滴滴智能中臺(tái) 體驗(yàn)平臺(tái)技 術(shù)團(tuán)隊(duì)幾乎支持了滴滴所有業(yè)務(wù)板塊客服系統(tǒng)的訴求，面對(duì)多樣性、邏輯變更快的業(yè)務(wù)場(chǎng)景，傳統(tǒng)的面向場(chǎng)景編程成本高且周期長(zhǎng)。因此我們建設(shè)了線上配置化的運(yùn)營(yíng)系統(tǒng)，讓運(yùn)營(yíng)、產(chǎn)品同學(xué)能夠通過畫流程圖的方式變更線上的業(yè)務(wù)邏輯，比如用戶電話進(jìn)線時(shí)的互動(dòng)式語(yǔ)音應(yīng)答、人工客服在處理用戶進(jìn)線時(shí)的標(biāo)準(zhǔn)作業(yè)流程、用戶自助解決問題的 H5 頁(yè)面配置系統(tǒng)等千人千面的應(yīng)用場(chǎng)景。

其次，各業(yè)務(wù)系統(tǒng)雖然都需要應(yīng)用流程可視化技術(shù)，但需求各不相同。有的對(duì)流程圖的要求比較簡(jiǎn)單，圖的數(shù)據(jù)格式也簡(jiǎn)單，而有的需要按照 BPMN 的規(guī)范來(lái)繪制流程圖，對(duì)于定制化的要求較高。我們調(diào)研了市面上相關(guān)的框架 （BPMN.js、X6、Jsplumb、G6-editor），均存在不滿足的場(chǎng)景，技術(shù)棧統(tǒng)一的成本很高。具體表現(xiàn)在：

• BMPN.js、Jsplumb 的拓展能力不足，自定義節(jié)點(diǎn)支持成本很高；只能全量引入，各系統(tǒng)無(wú)法按需引入；

• 與后端配套的流程引擎適配，成本較高。均不支持?jǐn)?shù)據(jù)轉(zhuǎn)換、不支持流程的校驗(yàn)等業(yè)務(wù)定制需求；

• 文檔、示例不健全。X6 和 BPMN 的文檔不健全，示例少（2020 初調(diào)研結(jié)論）。

因此，我們?cè)?2020 上半年開啟了 LogicFlow 的項(xiàng)目，支持各系統(tǒng)的流程可視化需求。

2. 

LogicFlow 的能力和特性

LogicFlow 當(dāng)前已具備了哪些能力呢，我會(huì)分兩部分來(lái)介紹：

▍ 1.  快速搭建流程圖編輯器

提供了一個(gè)流程圖編輯所必需的各項(xiàng)能力，這也是 LogicFlow 的基礎(chǔ)能力：

• 圖的繪制能力。 基于 SVG 來(lái)繪制形狀各異的節(jié)點(diǎn)和線，并提供了基礎(chǔ)的節(jié)點(diǎn)（矩形、圓形、多邊形等）和線（直線、折線、曲線）；

• 圖的交互。 根據(jù)節(jié)點(diǎn)、線、圖的各類鼠標(biāo)事件（hover、點(diǎn)擊、拖拽等）做出反應(yīng)。比如節(jié)點(diǎn)拖拽、拖拽創(chuàng)建連線、線的調(diào)整、雙擊節(jié)點(diǎn)編輯文本等；

• 提升編輯效率的能力。 提供網(wǎng)格、對(duì)齊線，上一步、下一步，鍵盤快捷鍵，圖放大縮小等配套能 力，幫助用戶提升編輯效率；

• 提供了豐富的 API 。 宿主研發(fā)通過 API 傳參調(diào)用和監(jiān)聽事件的方式，與 LogicFlow 完成交互。

通過以上能力，前端研發(fā)可以低成本、快速的搭建起流程可視化的應(yīng)用，提供流暢的產(chǎn)品交互。下面是通過 LogicFlow 內(nèi)置的節(jié)點(diǎn)和配套能力，做的流程圖示例：

▍ 2.  基于業(yè)務(wù)場(chǎng)景拓展

當(dāng)基礎(chǔ)能力無(wú)法滿足業(yè)務(wù)需求的時(shí)候，便需要基于業(yè)務(wù)場(chǎng)景拓展。這也是 LogicFlow 能支持客服側(cè)多個(gè)系統(tǒng)的核心能力。

• 設(shè)置圖上所有元素的樣式。 比如各種節(jié)點(diǎn)、線、錨點(diǎn)、箭頭、對(duì)齊線的大小顏色等，滿足對(duì)前端樣式調(diào)整的需求；

• API 拓展。 支持在 LogicFlow 上注冊(cè)自定義的方法，比如通過 API 拓展提供圖片下載的方法；

• 自定義節(jié)點(diǎn)、線。 內(nèi)置的矩形、圓形等圖形類節(jié)點(diǎn)往往無(wú)法滿足實(shí)際的業(yè)務(wù)需求，需要定義具有業(yè)務(wù)意義的節(jié)點(diǎn)。LogicFlow 提供了 的方式讓用戶定制具有自定義圖形、業(yè)務(wù)數(shù)據(jù)的節(jié)點(diǎn)，比如流程審批場(chǎng)景中的 “審批” 節(jié)點(diǎn)；

• 拓展組件。 LogicFlow 在 SVG 圖層上提供了 HTML 層和一系列坐標(biāo)轉(zhuǎn)換邏輯，并支持在 HTML 層注冊(cè)組件。宿主研發(fā)可以通過 LogicFlow 的 API，基于任何 View 框架開發(fā)組件，比如節(jié)點(diǎn)的右鍵菜單、控制面板等；

• 數(shù)據(jù)轉(zhuǎn)換 adapter。 LogicFlow 默認(rèn)導(dǎo)出的圖數(shù)據(jù)不一定適合所有業(yè)務(wù)，此時(shí)可以通過 adapter API，在圖數(shù)據(jù)從 LogicFlow 輸入、輸出的時(shí)候做自定義轉(zhuǎn)換，比如轉(zhuǎn)換成 BPMN 規(guī)范的圖數(shù)據(jù)；

• 內(nèi)置部分拓展能力。 基于上述拓展能力，我們還單獨(dú)提供了 extension 包，用來(lái)存放客服業(yè)務(wù)下沉淀出的具有通用性的節(jié)點(diǎn)、組件等，比如面向 BPMN 規(guī)范的節(jié)點(diǎn)和數(shù)據(jù) adapter，默認(rèn)菜單。注意 extension 可以單獨(dú)安裝，并支持按需引入 。

基于上述拓展的能力，前端研發(fā)能夠根據(jù)實(shí)際業(yè)務(wù)場(chǎng)景的需求，靈活的開發(fā)出所需的節(jié)點(diǎn)、組件等。下面有兩個(gè)基于 LogicFlow 拓展能力做出的流程圖：

BPMN

審批流程

▍ 3.  定位對(duì)比

上圖是通過橫縱兩個(gè)維度來(lái)對(duì)比目前大家耳熟能詳?shù)膸讉€(gè)開源框架，以了解 LogicFlow 的定位。橫軸是該框架在圖可視化能力的豐富程度，縱軸越靠上則代表這個(gè)框架在業(yè)務(wù)流程應(yīng)用上的成熟度越高，初次部署的開發(fā)成本越低。讓我們分別來(lái)介紹一下這幾個(gè)框架：

• activiti 作為工作流引擎提供了前后端的解決方案，簡(jiǎn)單二次開發(fā)就可以部署一套業(yè)務(wù)流程的管理平臺(tái)；

• Bpmn.js：基于 BPMN2.0 規(guī)范，設(shè)計(jì)的流程圖編輯器；

• G6：antv 旗下專注圖形可視化，各類分析類圖表。比如生態(tài)樹、腦圖、輻射圖、縮進(jìn)圖等等；

• X6：圖編輯引擎，核心能力是節(jié)點(diǎn)、連線和畫布。不僅支持了流程圖，還有 Dag 圖、ER 圖。

LogicFlow 的定位在上圖的 Bpmn.js 和 X6 之間，填補(bǔ)中間的空白。核心提供了流程圖的編輯器，并且通過拓展能力來(lái)支持 BPMN 等規(guī)范所需的流程節(jié)點(diǎn)和數(shù)據(jù)格式，以滿足當(dāng)前業(yè)務(wù)下的現(xiàn)狀。

3. 

實(shí)現(xiàn)原理和架構(gòu)

▍ 1.  整體架構(gòu)圖

核心包 @logicflow/core 提供了流程圖編輯器基礎(chǔ)的能力，右邊的 @logicflow/extension 是基于 @logicflow/core 的拓展性開發(fā)的插件。

▍ 2.  流程圖編輯器的設(shè)計(jì)方案

主要介紹一下實(shí)現(xiàn)流程圖編輯器重要的選型和方案設(shè)計(jì)：

2.1 圖渲染方案

前端繪制圖形無(wú)非就是 HTML + CSS、Canvas、Svg 三種方式，我們綜合做了一下對(duì)比，列出了相應(yīng)的優(yōu)劣勢(shì)：

在流程圖的場(chǎng)景下，不需要渲染大量的節(jié)點(diǎn)（最多幾千個(gè)元素），對(duì)于動(dòng)畫的訴求也不高。Svg 基于 DOM 的特性會(huì)更適合我們，一個(gè)是學(xué)習(xí)成本和開發(fā)成本更低，另一個(gè)是基于 DOM 可以做的拓展也更多。不過 Svg 標(biāo)簽內(nèi)部并不支持插入其他比如 div 這種標(biāo)簽，所以在實(shí)現(xiàn)某些功能的時(shí)候，都需要結(jié)合其他 HTML 標(biāo)簽。

所以最終我們選擇使用 HTML + Svg 來(lái)完成圖的渲染，Svg 負(fù)責(zé)圖形、線的部分，HTML 來(lái)實(shí)現(xiàn)文本、菜單、背景等圖層。

2.2 模塊抽象

基于上述方案，下一步我們要做的是對(duì)實(shí)現(xiàn)一張流程圖做分類和抽象。

通過上圖：

• 我們構(gòu)建了多個(gè)圖層來(lái)承擔(dān)不同的職責(zé)，以方便實(shí)現(xiàn)功能和能力拓展。最上層的是 Svg 圖層，所有圖形（節(jié)點(diǎn)、線、對(duì)齊線、outLine 等）均在 Svg 上渲染，也負(fù)責(zé)監(jiān)聽圖上的各種事件。Svg 下層的分別是組件層，負(fù)責(zé)拓展 UI 組件；Grid 層，負(fù)責(zé)渲染網(wǎng)格；背景層，添加自定義的背景；

• Shape 的職責(zé)主要是基于 Svg 對(duì)圖形渲染的封裝，提供默認(rèn)樣式、把用戶傳入的屬性做轉(zhuǎn)換等，主要包含 Rect、Circle、Ellipse、Polygon、Path、PolyLine、Text 等，方便 LogicFlow 內(nèi)部復(fù)用，比如圓形節(jié)點(diǎn)和錨點(diǎn)都需要 Circle；

• 基于 Shape，還實(shí)現(xiàn)了很多小元素，比如節(jié)點(diǎn)和線需要的錨點(diǎn)，比如線上的箭頭等等；

• 而 BaseNode、BaseEdge 則是節(jié)點(diǎn)和線通用能力的封裝，聚合 shape、錨點(diǎn)、文本，還封裝了對(duì)事件和樣式的處理等。通過繼承 BaseNode，傳入 shape 我們可以得到 RectNode、CircleNode 等可渲染的節(jié)點(diǎn)。

因?yàn)榱鞒虉D是富交互或者說(shuō)是重編輯的，有了這幾個(gè)基礎(chǔ)的模塊，接下來(lái)要做的就是富交互的方案設(shè)計(jì)，即用戶在圖上做的任何操作都要給出響應(yīng)。比如我觸發(fā)一個(gè)節(jié)點(diǎn)的拖拽，那關(guān)聯(lián)的線可能需要跟著動(dòng)，還能識(shí)別出在某個(gè)水平線上有沒有其他節(jié)點(diǎn)（對(duì)齊線）。

2.3 MVVM + Virtual DOM

首先我們考慮到整個(gè)圖編輯器具備很多狀態(tài)存儲(chǔ)，并且要實(shí)現(xiàn)編輯圖上各模塊的響應(yīng)就必須要有狀態(tài)的通信能力。第二如果要實(shí)現(xiàn)類似 redo/undo 這類功能，那整個(gè)圖就一定需要根據(jù)數(shù)據(jù)得出渲染，即 fn(state) => View ，比較好的方式就是通過 Model 來(lái)驅(qū)動(dòng) View。

最終我們選擇基于 MVVM，這個(gè)廣泛被應(yīng)用于當(dāng)前前端工程中的設(shè)計(jì)模式來(lái)構(gòu)建 LogicFlow 的圖編輯器，定義圖的 View 和 Model 層，使工程代碼具備一定的解耦。與此同時(shí)，引入 Mobx 來(lái)實(shí)現(xiàn)我們的狀態(tài)管理、數(shù)據(jù)響應(yīng)的能力，一張圖基于一份 Model 做狀態(tài)的通信。此外，考慮 Mobx 的另一個(gè)原因是：只要我想，那就可以做到最細(xì)顆粒度的數(shù)據(jù)綁定（觀測(cè)），可以減少?zèng)]必要的渲染。

以下是 LogicFlow 圖編輯器的 MVVM 示意圖：

通過上圖可以看到，View 層（圖、節(jié)點(diǎn)等）通過數(shù)據(jù)綁定，會(huì)在 Model 發(fā)生變化之后做出響應(yīng)/更新。前面我們提到了關(guān)于圖的渲染我們是基于 Svg + HTML 實(shí)現(xiàn)的，那要做 View 層的更新無(wú)非就是命令式和聲明式兩個(gè)選擇：

• 命令式。 比如 jQuery 的 api，$('.rectNode').attrs({x: 1, y: 2})，像這種方式操作 DOM 代碼其實(shí)比較繁瑣，在重交互的場(chǎng)景下寫的代碼會(huì)比較冗余。雖然我們最終找到了有一個(gè)庫(kù)能夠很方便的支持通過命令式的方式來(lái)繪圖 —— antv/g。

• 聲明式。 比如 React/Vue 這類 View 框架，其中一個(gè)比較核心的能力就是做到了 state => UI ，通過聲明式的方式來(lái)構(gòu)建 DOM，只要狀態(tài)發(fā)生變化，那 UI 就更新。

除了考慮到命令式在操作 DOM 的場(chǎng)景下寫代碼會(huì)比較繁瑣之外，還有一個(gè)原因就是操作 DOM 的成本問題，在基于 State 更新 UI 的設(shè)計(jì)下，我們自然而然想到了引入 Virtual DOM 來(lái)解決某些場(chǎng)景下的更新效率，這也可以一定程度上彌補(bǔ)「基于 Svg 渲染圖形」可能造成的渲染性能問題。

總之，選擇 MVVM 的設(shè)計(jì)模式并引入 Virtual DOM，最根本的兩個(gè)原因是：

• 提升我們圖編輯器場(chǎng)景下的開發(fā)效率。

• 以及在 HTML + Svg 的圖渲染方案下，可以追求更好的性能表現(xiàn)。

我們與 X6 做了一次渲染時(shí)的性能比較，在相同的運(yùn)行環(huán)境下，分別測(cè)出 LogicFlow 和 X6 在不同量級(jí)的節(jié)點(diǎn)/線下，渲染出流程圖的時(shí)間，理論上渲染時(shí)間越短，性能表現(xiàn)約好。

通過上述表格，我們測(cè)算出 LogicFlow 在初始渲染速度上是優(yōu)于 X6 的，并且這還沒有開啟LogicFlow  的按需加載功能，也驗(yàn)證了我們的技術(shù)選型。你也可以在示例頁(yè)進(jìn)行測(cè)試：

https://yhlchao.github.io/LF-VS-Other/

2.4 事件系統(tǒng)

介紹了在 “狀態(tài)” 和 “響應(yīng)” 我們做的設(shè)計(jì)，那要收集到用戶的各類 “操作” 并及時(shí)上報(bào)和冒泡，就需要一套事件系統(tǒng)。最主要的就是復(fù)用和統(tǒng)一上報(bào)。

復(fù)用即怎么保證所有節(jié)點(diǎn)和線都能具備默認(rèn)的事件回調(diào)，以及針對(duì)復(fù)雜事件（拖拽）的處理邏輯如何共用。

• Behavior。針對(duì)復(fù)雜事件的處理，我們做了 function 和 class 形式的封裝，比如 Drag 是通過 mousemove、down、up 來(lái)模擬 h5 的 dragEnter、dragOver、dragEnd 和 drop 事件，DnD 則是通過抽象 dragsource 和 droptarget 兩個(gè)實(shí)體來(lái)實(shí)現(xiàn) drag 和 drop 的交互，比如拖拽創(chuàng)建節(jié)點(diǎn)；

• 在前文模塊抽象章節(jié)提到了內(nèi)部有 BaseNode 和 BaseEdge 這樣的抽象，內(nèi)置節(jié)點(diǎn)和自定義的節(jié)點(diǎn)都通過繼承基類來(lái)獲得通用的能力，所以 LogicFlow 內(nèi)部默認(rèn)的事件回調(diào)實(shí)際是通過繼承來(lái)復(fù)用的；

• EventCenter。通過事件總線做統(tǒng)一上報(bào)，把內(nèi)部捕獲到的所有用戶行為事件，按照一定的規(guī)范和格式 emit(ev, args) 都上報(bào)到 EventCenter，最終冒泡到 LogicFlow 類，由 LogicFlow 類統(tǒng)一跟宿主交互。此外，圖編輯器內(nèi)任何地方也都可以通過 EventCenter 做事件的觸發(fā)和監(jiān)聽。

2.5 工具中心

工具中心的定位是解決某類特定問題的 utils，比如上面提到的 Behavior（復(fù)雜事件的封裝） 和 EventCenter。此外，在圖編輯的過程中，如果要實(shí)現(xiàn)比較好的交互效果，實(shí)際有很多復(fù)雜的計(jì)算邏輯要處理。

• 坐標(biāo)系。 瀏覽器的 clientX、clientY 坐標(biāo)系，以及 Svg 圖本身的坐標(biāo)系，當(dāng)出現(xiàn)圖的縮放和平移的時(shí)候，兩個(gè)坐標(biāo)系是不同的，在事件處理的時(shí)候就需要做兩個(gè)坐標(biāo)系的轉(zhuǎn)換。

• Algorithm。 是專門通過幾何、算法來(lái)處理可視化的一些問題。比如： 當(dāng)一個(gè)節(jié)點(diǎn)在同一方 向有多條折線連出的時(shí)候，如何做路徑的合并以展示起來(lái)更美觀，如下：

如何計(jì)算出一根線到一個(gè)圖形的切點(diǎn)，以達(dá)到線可以連接圖形非錨點(diǎn)的位置，如下圖：

• History。 主要提供 redo 和 undo 的能力。通過兩個(gè)棧來(lái)存儲(chǔ) undos 和 redos，并限制最大長(zhǎng)度，得益于 MVVM 的設(shè)計(jì)模式，能方便的做數(shù)據(jù)變化的觀測(cè)和 Model 驅(qū)動(dòng) View。

▍ 3.  可擴(kuò)展性

介紹完流程圖編輯器的設(shè)計(jì)方案，現(xiàn)在來(lái)介紹 LogicFlow 的另一個(gè)重要特性，關(guān)于拓展性方面的設(shè)計(jì)。對(duì)于 LogicFlow，是解決某個(gè)領(lǐng)域問題的開發(fā)框架，首先 API 要具備可擴(kuò)展性；此外 LogicFlow 還提供了視圖層，在 View 部分應(yīng)該能夠讓用戶做二次開發(fā)。這兩個(gè)擴(kuò)展的方向確定之后，最主要的還是結(jié)合業(yè)務(wù)需求，要能滿足當(dāng)前和未來(lái)一段時(shí)間內(nèi)預(yù)見的業(yè)務(wù)場(chǎng)景，但也不能過度設(shè)計(jì)。

3.1 API 上的設(shè)計(jì)

首先，LogicFlow 在面向用戶使用這一層，完全是基于面向?qū)ο蟮脑O(shè)計(jì)模式封裝的，最大的好處是幾乎每個(gè)程序員都熟悉它的使用，使用成本低。通過下面初始化方式便可以了解。

通過 class LogicFlow，用戶實(shí)例化一次便得到一個(gè)流程圖的實(shí)例，狀態(tài)也是私有的，各種使用方法通過 lf 的實(shí)例調(diào)用即可。

關(guān)于 API 拓展的設(shè)計(jì)總結(jié)來(lái)看：

• 面向?qū)ο蟮脑O(shè)計(jì)模式， LogicFlow 內(nèi)部做好封裝，用戶可以做繼承、重寫接口/方法；

• 方法的設(shè)計(jì)。首先是要有固定類型的輸入和輸出。此外，LogicFlow 也提供了類似于 extends 的方法，通過  LogicFlow.use(fn) 在原型上拓展方法；

• 通過觀察者的模式做通信，即提供 on 方法供宿主訂閱各類內(nèi)部事件；

• 圖的數(shù)據(jù)可定制。無(wú)論是一個(gè)節(jié)點(diǎn)、線有哪些自定義的業(yè)務(wù)屬性，還是流程圖要導(dǎo)出什么樣的數(shù)據(jù)，都應(yīng)該能夠定制。

3.2 插件化

View 層的拓展性，除了用戶能夠定制展現(xiàn)方式之外，最重要的是插件化，因?yàn)樵诹鞒炭梢暬@條路上，不同的業(yè)務(wù)場(chǎng)景下需要的能力不盡相同，LogicFlow 很難做到支持所有的場(chǎng)景，所以提供好的插拔能力，讓用戶二次開發(fā)是比較好的選擇。 目 前，在 UI 界面上，我們開放了兩個(gè)能力：

• 節(jié)點(diǎn)和線支持二次開發(fā)，即自定義節(jié)點(diǎn)、線。

• 可開發(fā) UI 組件注冊(cè)到 LogicFlow 的組件畫布內(nèi)。

基于插件化的思路，我們已經(jīng)支持了不同的業(yè)務(wù)系統(tǒng)，并在這個(gè)過程中把一些稍微通用的能力沉淀出來(lái)，并封裝到 lf-extension 包，比如用來(lái)支持 BPMN 規(guī)范的節(jié)點(diǎn)。目前 extension 內(nèi)的拓展主要分了四類：UI 組件、自定義節(jié)點(diǎn)、API、adapter。

4. 

未來(lái)規(guī)劃

首先是API 的易用性和豐富程度。具體的功能 scope 除了我們當(dāng)前的迭代計(jì)劃（詳見 github 倉(cāng)庫(kù)的 project），還會(huì)根據(jù)用戶的需求排出優(yōu)先級(jí)后加入進(jìn)來(lái)，也希望大家多多提意見和需求。這個(gè)方向的基調(diào)是保持 LogicFlow 流程可視化的定位，把 core 的 API 豐富，extension 的能力增強(qiáng)。

其次是更完善的文檔和示例。主要是文檔易讀、完善，能夠有完整的示例和代碼，供開發(fā)者 copy paste 代碼，目前示例只有 react 版，2021.4 之前會(huì)增加 vue 版的示例。

最后，不僅是流程可視化庫(kù)，更期望提供整套解決方案。LogicFlow 只解決了前端流程圖編輯的技術(shù)問題，但關(guān)于圖數(shù)據(jù)的定義，流程最終如何被執(zhí)行，還需要一個(gè)配套的流程引擎。

目前，關(guān)于「流程引擎」我們團(tuán)隊(duì)也有相應(yīng)的解決方案 —— turbo（Java 版已開源：https://github.com/didi/turbo），我們會(huì)把 LogicFlow 和 turbo 做成端到端的解決方案，并提供完整的應(yīng)用示例。此外，Nodejs 版的引擎也在規(guī)劃中，大家拭目以待。

5. 

寫在最后

通過本文相信你對(duì) LogicFlow 已經(jīng)有一個(gè)大概的認(rèn)識(shí)了，如果在你負(fù)責(zé)的業(yè)務(wù)中也有流程可視化的訴求，并且有較高的拓展性需求，那 LogicFlow 會(huì)是一個(gè)好的選擇。 對(duì)于 LogicFlow 技術(shù)本身的實(shí)現(xiàn)細(xì)節(jié)、對(duì)于相似業(yè)務(wù)的探討也都?xì)g迎大家來(lái)交流。 我 們后續(xù) 會(huì)有更多的文章介紹 LogicFlow 在技術(shù)設(shè)計(jì)細(xì)節(jié)以及我們對(duì)于可視化、業(yè)務(wù)流程、邏輯編排等領(lǐng)域的一些思考，盡情期待。

LogicFlow 官方網(wǎng)站： http://logic-flow.org/

github 倉(cāng)庫(kù)地址： https://github.com/didi/LogicFlow