換個角度：採用時間建模來捕捉時間的流逝 - Mario

banq發表於2022-12-10

建模是軟體或系統開發的一個重要部分，然而在試圖捕捉系統的行為時，並不常見到時間被使用。當我們這樣做時，我們傾向於提取這個概念，並以計劃任務的形式將其放在領域之外。

在這篇文章中，我將提倡把時間作為建模的起點，並建議偏離傳統的排程器，而採用更加反應式的模型。

傳統的方法
傳統建模很有可能是以下之一。

  • 類圖
  • 實體關係圖
  • 資料模型


雖然這些人工製品沒有任何問題，但它們都代表或集中於你的系統在其生命週期內將處理的事物的結構。它們未能講述上述事物是如何被創造並演化為當前狀態的故事。

想想領域驅動設計（DDD），在其中你將尋求定義實體、值物件，以及在其行為方面的聚合。即使採用這種方法進行軟體設計，時間建模也是一個挑戰，因為這些概念很少由領域專家來定義。相反，它們需要透過反覆的討論才能發現。

考慮到上述困難，讓我們嘗試一種不同的方法，將重點從結構轉移到一段時間內發生的事情。

時間性建模
時間模型Temporal Modeling不是試圖從結構和關係開始，而是試圖透過探索來發現你的領域的複雜性。這導致了結構和關係，但以一種更容易讓他人參與討論的方式。

讓我們看一個例子來說明應用這種建模的一種方式。想象一下一個電子商務系統，我們有一個用例，從客戶下訂單開始。我將使用事件風暴的記號：

換個角度：採用時間建模來捕捉時間的流逝 - Mario

當你看我們的例子時，時間被放在了聚光燈下。我們代表了我們的系統在對已經發生的事實做出反應時是如何演化的。你把討論的重點放在事實上，然後演化出如何命名出現的概念，以及它們的行為的決定。

現在讓我們來看看，當時間的流逝本身是一個你可以建模的事件。

時間的流逝
在我們以前的電子商務系統中，經過對客戶行為的分析，已經確定X%的客戶傾向於在購買後30分鐘內改變主意。為了減少在倉庫處理這些變化後不必要的複雜性和成本，我們引入了悔改期。然後，決定是這樣被捕獲的。

換個角度：採用時間建模來捕捉時間的流逝 - Mario

請再次注意，這種行為是由一個事實表示的：時間已經過去，悔恨期已經過了。

從實現的角度來看，這通常被表示為一個計劃任務，尋找符合我們所尋找的標準的專案。

SELECT orders WHERE creationDate < now - 30min AND status = Approved


這個偽SQL可以被你在持久化機制中使用的任何方法取代。如果我們一直在使用事件，而且我們的應用程式本質上是反應性的，為什麼不嘗試使用這種方法呢？

重新思考排程程式
使用排程器的解決方案--對於那些利用基於Linux的系統的人來說，cron是一種傳統的方法。雖然這種方法可行，但它有一些缺點。

  • 可能是低效的。因為它使用了一個 "輪詢 "機制，它可能必須每分鐘執行一次，即使沒有訂單透過悔恨期，也要執行查詢。
  • 需要你處理/防止併發的執行。如果你有大量的訂單透過了悔恨期，當下一個執行期到來時，計劃任務可能還在處理上一批訂單。
  • 削弱了領域知識。悔恨期（30分鐘）是一個重要的概念，但在領域本身卻找不到。在最壞的情況下，它可能分散在領域和一個外部/基礎設施元素（排程器）之間。


前兩個缺點並不新鮮，可以說有技術解決方案，以輔助庫或服務的形式來減輕它們的影響。然而，最後一個問題卻超越了普通的產品。

讓我們看看一個試圖解決所有三個方面的概念實現：
  • 在訂單被批准後，我們將在未來釋出一個事件RmorsePeriodExpired，其中包含預期的最後期限。
  • 在這個時間用完後，該事件將供訂單系統使用，然後它將透過內部鎖定訂單來防止它在未來被改變。



測試
建模時間的一個副產品體現在定義你的測試時，因為它們變得更加明確，並與用例定義的語言相一致。


情景：如果悔恨期已過，訂單應被鎖定
鑑於訂單已獲批准
當悔恨期過後
那麼就鎖定了訂單


正如我們所看到的，它比替代方案更有表現力，也更容易編寫，因為替代方案很可能太接近於基礎設施。

結論
注重結構的傳統方法，即使是領域驅動的，也有侷限性，而且往往很難讓非技術性的利益相關者參與進來。另一方面，其他基於講故事的方法，包括基於時間模型的方法，透過將討論集中在已經發生的事實上，鼓勵使用者的參與。

事件風暴或故事圖是一些被推薦的方法，可以幫助從本質上翻轉事情，專注於事件、時間線，並最終導致概念的定義，這些概念將成為你的泛在語言的一部分。

利用這種方法，如果你的系統具有反應性，就不要猶豫，將時間的流逝作為事件來捕捉。在與業務有關的流程中，如果涉及到訂單、訂閱或支付，這些比你想象的更常見。

最終你會擁有直接或間接代表時間流逝的事件，這不僅使它們成為一流的概念，而且還使用你的應用程式可能已經在使用的相同的訊息基礎設施。

 

相關文章