持續建模，關注業務抽象，以任務分派執行跟蹤系統為例

showerxp發表於2013-09-08
抽象
前言：我認為，抽象和封裝是物件導向程式設計思想的精華，這在兩年前我已經發過這方面的帖子了。現實中，給無OO建模概念的人員直接交流OO建模是何等困難!他們恪守著資料庫建模，程式碼優先的律令，無論我如何強調關注業務本身，對業務抽象，實現業務軟體模型和現實世界對映的重要都無濟於事。經常發生的現象可能是：我說的理論性強一些，會被視為花架子，難以實現；我說個簡單的需求作為例子，還沒有說出如何抽象建立OO模型，別人就資料建模出來了，表示出資料建模方法的高效率，而對OO建模帶來的參與者溝通的便利、團隊協作開發的保障、應對需求必定變化的優勢等優點視而不見。發生這種尷尬現象來自於我的原因，還是篤定的這套理論系統落地實現案例太少，關注業務變化本身的程式設計思想還不為多數人認同。因此，本人斗膽借用“Just Do It”精神發此貼，將討論重點放在業務上，說明——挖掘業務需求，抽象歸納是如何適應需求的變化。
但是，我並不否認程式導向程式設計方法論，並不否認軟體實現最終還是要資料庫建模。我只是認同罈子裡很多人的觀點：將資料庫建模的戰略地位降低一點，作為物件持久化來看待；將程式碼編寫階段拖後一些，先看看客戶需求，以及應對變化需求的解決方法。

正文：唯一不變的是變化。
需求一：
客戶要求做一個任務分派跟蹤系統，業務流程大致如下：公司經理可以給部門職員分派任務；任務包括任務說明、要求、完成時間等內容；部門職員收到分派的任務之後限期完成，報公司經理辦理情況；系統根據任務限期時間，對於未完成任務的經辦人傳送提醒；系統對於超期完成的任務執行情況進行記錄。
一個具體的例子：部門經理要求所有職員在2013年1月1日之前報一份2012年度工作總結。
資料庫建模可能是這個樣子：任務表（包涵任務Id、任務要求、任務期限、分派人、執行人、完成時間等欄位）；任務提醒設定表（包涵Id、任務Id、距離任務限期提醒週期（比如距離任務結束還有1小時、8小時、12小時等）、提醒內容）；成員表（包涵Id、成員名、賬戶、密碼、職位（經理和職員））。
由於需求明確、簡單，程式碼部分就是實現以上資料庫模型的crud操作，那些簡單的業務流程完全可以寫入crud操作中，例如判斷當前時間是否到了該傳送提醒未完成任務的經辦人時間。
這樣做出的軟體效率高，同時滿足了需求一，假設這個軟體成為軟體系統一。

相關文章