接觸工作流：
最早接觸工作流，是在04年左右，那年，我創造了 Aries 框架的前身第一版框架，另一個同事，創造了工作流的第一版框架。
只是那時候，我並未參與工作流的核心設計，僅僅是幫寫了個流程設計器，就是下圖這個懷舊的樣子：
然后提供一些（撤回、退回）回收算法的意見。
並提供：CYQ.Data 的源碼作為底層數據層，那時候還沒開源 CYQ.Data。
悲催的是，同事拿到 CYQ.Data 框架的源碼，卻把它打散了，沒用MAction，只用MProc，並來了個二次封裝，把sql語句搞了一堆配置的xml文件，估計是被mybatis毒害了。
以至於后來，有一個項目要用到oracle時，呵呵就兩個字：
好在手頭上還有舊版本的源碼，把報錯的xml配置Sql文件重寫，把相關調用視圖語句也重寫，勉強在當時的項目流程里不報錯。
配置的xml語句太多，全部檢測和重寫不現實，畢竟對工作流框架一丁點都不熟。
估計那時候的人年輕啊，所謂的支持多數據庫，都是喜歡這么坑人的，
就像現在，喜歡用Dapper的，玩玩支持單數據庫還可以，若是支持多數據庫，那也是一個大坑。
了解工作流：
說起來，當年，那么多項目都用到工作流，我卻沒有涉入，連怎么使用都沒學，更別說了解工作流框架的核心思想了。
只是后來，那個oracle項目，讓我不得不接觸工作流，因為報錯啊!
那時候的我還在全力重寫Aries，作為技術支持，我只好稍為了解下工作流。
不了解還好，一了解就頭大，這代碼，這命名，這邏輯，我槽，跟我高中時讀英文作文有啥區別，一圈下來，就三字：看不懂。
好在，有時候解決問題，並不需要你懂它，只要運行，看到哪里報錯，把報錯相關的地方，修改一下就可以了。
后來，Aries上線了，不過卻沒有配套工作流，因為機制不一樣，Aries的純天然html，和早期工作流的aspx,ascx不協調。
重構或重寫工作流？
開始想重構，不過在前前后后看了一個多月的源碼后，就放棄了，舊同事能把代碼寫的天然帶混淆效果，我也是服了。
放棄了重構，按自己的思維，重寫吧，新重寫的工作流初命名是叫：Scorpio（天蠍座）才剛設計好數據庫，寫了個開頭，就被各種事情打斷了，然后妖折了。
這重構和重寫是有區別的：
重構，是需要了解原作者的思路，並逐步進行改進，或重寫。
重寫：不需要了解原作者的思路。
后來，工作流這事就放下了，放下了好幾年。
直到去年，老東家讓我幫解決工作流上的一個問題，
畢竟當年框架的原始作者已經離開了，二次接手維護的人，也離開了，估計也沒人敢三次接手維護了。
因此又讓我重拾了工作流了：
又看那天書般的工作流代碼，唉，好在一周后，感覺好像看懂了一些，問題也幫解決了〜
掐指一算：是時候為 Aries 配上工作流了
前前后后，接觸和了解工作流也好幾年了。
Aries也出來很多年了，是時候配上工作流了。
於是，動手了，只是沒想到，兩個多月，無眠不休，才重寫完。
除了流程圖的樣式有所保留，其它代碼全部重寫了： 
關於框架取名：Gemini.Workflow，簡稱：雙子流
終於，十二宮，迎來了新的成員：Gemini（雙子座）
嗯，現在已經集齊四個，還差八個就可以招喚雅典娜了：
Aries（白羊座）：.NET Develop Framework（適合場景：業務系統、內部信息系統、后台管理系統、ERP，支持.NET Core）
Taurus（金年座）：Taurus.Mvc（適合場景：對性能和並發有較高要求的電商、站點、WebAPI等系統，支持.Net Core）
Gemini（雙子座）：Gemini.Workflow 使用簡單，功能強大的工作流框架。
Sagit（射手座，Sagittarius）：IOS Develop Framework（Sagittarius 射手座：IOS下的一套基礎快速開發框架）
入門教程：
1、Gemini.Workflow 雙子工作流入門教程一：定義流程：流程圖屬性
2、Gemini.Workflow 雙子工作流入門教程二：定義流程：流程節點介紹
3、Gemini.Workflow 雙子工作流入門教程三：定義流程：流程節點、遷移條件參數配置
4、Gemini.Workflow 雙子工作流入門教程四：流程應用
5、Gemini.Workflow 雙子工作流入門教程五：業務表單開發
API文檔：
后端：Gemini.Workflow API 文檔和 前端： Gemini.Workflow.js API 文檔：
https://github.com/cyq1162/Aries/tree/master/Aries.Document
總結：
目前 Gemini.Workflow 雙子流是配套在 Aries 中，兩者結合，成為更加強大的業務系統基礎開發框架。
框架地址：https://github.com/cyq1162/Aries