spring statemachine的企業可用級開發指南1-說些廢話

一、背景

    在我打算學習spring statemachine的時候，我幾乎看過了全部網上的中文教程，基本上都處於淺嘗輒止的階段，有幾篇講的比較深刻的，都只是堆代碼，具體用在什麼地方，都語焉不詳，我打算把我一路摸索的過程記錄下來，方便你們能繼續前行。

二、spring statemachine是幹啥用的

    spirng statemachine是幹啥用的，這個實際上是個問題來的，但不少的教程的問題也在這，一上來就是告訴你有這麼個玩意，而後就是開始怎麼安裝，怎麼運行，功能有哪些，特性列起來，但就不告訴你這個東西能幹啥，因此我打算在把spring statemachine跑起來以前，先說下spring statemachin能幹啥。讓咱們先看下狀態機的概念。

    有限狀態機（英語：finite-state machine，縮寫：FSM），簡稱狀態機，是表示有限個狀態以及在這些狀態之間的轉移和動做等行爲的數學模型。應用FSM模型能夠幫助對象生命週期的狀態的順序以及致使狀態變化的事件進行管理。將狀態和事件控制從不一樣的業務Service方法的if else中抽離出來。FSM的應用範圍很廣，對於有複雜狀態流，擴展性要求比較高的場景均可以使用該模型。下面是狀態機模型中的4個要素，即現態、條件、動做、次態。

現態：是指當前所處的狀態。
條件：又稱爲「事件」。當一個條件被知足，將會觸發一個動做，或者執行一次狀態的遷移。
動做：條件知足後執行的動做。動做執行完畢後，能夠遷移到新的狀態，也能夠仍舊保持原狀態。動做不是必需的，當條件知足後，也能夠不執行任何動做，直接遷移到新狀態。
次態：條件知足後要遷往的新狀態。「次態」是相對於「現態」而言的，「次態」一旦被激活，就轉變成新的「現態」了。

    這是狀態機的定義，這個我不打算多說，由於概念性的東西，諸位請自行搜索，那麼在實際應用中，狀態機會應用在什麼地方呢？不知道你們怎麼想，我在接觸到狀態機的時候，第一時間想到的就是訂單和審批公文，這是我在工做中實際遇到的場景，因此我學習spring statemachine的主要動力也是爲了能處理這兩種狀況。由於訂單和審批公文都有不少的流程，每一個流程都會產生狀態的變化，並且流程是這種業務的主軸，其餘都是圍繞這個流程和狀態變化來考慮的，因此看起來蠻適合用狀態機來作。

    那是否是必定要用狀態機來作呢，這可不必定，由於在沒有狀態機以前的訂單流程你們也能實現，這世界缺了誰都正常運轉，因此狀態機不是必須的，在能夠用狀態機解決這種流程和狀態變化的場景下，爲何要用，這是另一個問題，由於能夠用和決定用之間，還有個問題，那就是用這個有啥好處呢？

三、spring statemachine的好處

    在作軟件項目的時候，咱們會以各類各樣的角度看一個項目，好比OOP，萬物皆對象，一個訂單就是一個對象，所謂的狀態變化，無非就是訂單這個對象的變量在不停的變化，變化的過程就是對象的方法；再好比數據庫，萬物無非CRUD的組合，訂單不過就是增刪改查，數據庫原子操做的組合罷了。這些角度對嗎？能夠說都對，由於用這些角度都有人作出了項目，但有些角度對項目的理解會比較方便，有些角度就比較費勁，好比訂單，若是是訂單的生成查看，用CRUD就是很適合，由於這個角度很契合；若是是訂單和商品的關係，訂單和其餘業務的關聯，OOP的角度就很適合，由於用封裝、多態的視角比較容易看清楚這類業務和他們之間的邊界，方便劃分各自的功能。而狀態機的角度，就是以狀態變化和流程運轉爲角度切入看問題，因此對於流程性爲主軸的項目就很適合，因此是否是用spring statemachine，衡量的標準就是，這個項目的主軸，或者場景是否是一個流程性、狀態變化爲主的項目，若是是，就能夠考慮用spring statemachine了。

    這個問題其實還沒回答完，上面說的實際上是在什麼狀況下用spring  statemachine，但還沒回答好處在哪裏。要回答這個問題，要從軟件項目的一些特質提及。上面說了，軟件項目其實有不少的辦法完成，手段不少，完成的狀況也各有優劣，那怎麼判斷用什麼辦法好呢，我以爲答案就是看項目主要解決的問題是什麼。軟件項目既不是程序員練手的工具，也不是老闆用來蒙錢的門面，它是用來解決問題的，因此能清晰的表達問題，解決問題的手段就是好的技術手段，因此，若是一種技術手段很清晰的表達了軟件項目的問題和解決方法，那麼這就是這個技術最大的好處，而狀態機對於流程性、狀態變化的場景，它就是一個清晰的表達方式，這就是它的好處。

    這樣說可能有些朋友會不覺得然，一個技術框架的好處難道不是功能強大，使用方便，性能卓越這些東西嗎。個人理解是上面說的這幾點都很重要，但都是次一級的問題，能清晰的表達問題和解決問題的，纔是核心的好處。在《人月神話》的《沒有銀彈》這篇文章裏面就提到過軟件特性的根本困難和次要困難，而對問題的表達和解決其實就是對需求的準確描述和實現，這就是軟件開發的根本困難，因此可以清晰表達這個的技術框架，就是解決根本困難的好工具，項目技術選型最重要的好處考量。至於功能、性能這些，都是次要問題，雖然spirng statemachine在次要問題上也並無什麼缺陷。

    好了，廢話時間結束，下一章，咱們正式開始第一個例子，運行一個demo，請你們期待，由於這個例子真的沒啥用：）