系統設計其實很有趣–從商務邏輯談起

對於什麼是商務邏輯，每個人都有自己的看法，我就講講我自己的想法，歡迎大家討論。

我想判斷某個部分是不是商務邏輯，一個最簡單的方法就是與另一個完全不同的系統進行比較，如果該問題在另一個系統中不存在了，則它就是這個系統的商務邏輯，否則就不是。

商務邏輯應該是一個系統區別於另一系統的本質所在。

例如，一個現金報銷單的審批程式，不同人員對不同金額的審批許可權明顯就是屬於商務邏輯的範疇，因為請假審批程式則不會有此問題存在。

一張請假單必須註明代理人和代理的事項，便是請假審核程式的商務邏輯。

商務邏輯同時還包括：

請假單必須註明請假人，請假時間，原因，假別等

請假單有四種狀態：草稿，審核中，已核准和已拒審

滿一年才有年假，五年以內七天，十年以內十天

病假一年最多三十天，超過只能作為事假請

只有草稿狀態的請假單才可以刪除

事假超過二十天需要總經理批准

只有人事主管才可以查看所有部門的請假資料

部門主管只可以查看本部門的資料

任何系統使用者只能看到自己的請假單。

請假單核准後，將資料轉入公司的考勤系統

...

像這些業務對象的描述，規則，許可權，流程等等都應該屬於商務邏輯的範疇。

而與之相對的，則是屬於非商務邏輯部分，是所有系統設計時都應該考慮的：

1.如何?資料訪問（以及事務的處理）

2.異常處理

3.日誌和追蹤如何?

4.緩衝策略的設計

5.對象的動態組裝和更新替換

6.以何種UI呈現

7.UI與系統服務如何銜接

8.系統如何分層，各層之間如何銜接

...

上面這些我想是一個系統的基本架構，是系統的底層架構。

 

因此整個系統分為2個問題域

1.商務邏輯：與系統如何?無關，例如是C#還是Java,B/S 還是 WinForm,Oracle還是Sql Server。

2.底層架構：與商務邏輯無關，大多與軟體實現方式相關。

 

使用者大部分時候比較關心商務邏輯，當然他可能要求要Oracle以及web方式實現。如果是這樣，則底層架構的設計會依賴在某一具體平台之上。

 

很多時候，UI也是有商務邏輯的。

如對於不同類別請假單顯示為不同顏色，這其實也屬於商務邏輯的一部分。

if(核准) 

  color = "綠色"

else if(拒審)

  color = "紅色"

else if(審核中)

  color = "藍色"

else

  color = "黑色"

 

因為當哪天需求發生變更，又多了一種狀態（如退回），也要修改此UI程式。

 (PS：這裡講的商務邏輯是與基礎架構相對應的，和園子裡其它朋友劃分UI層，商務邏輯層，資料訪問層的外延不一致)

 

識別出了商務邏輯，那設計時應該如何?這些商務邏輯了。

最傳統的方法就是結構化分析與設計了，即SA(Structure Analysis)和SD了

當然還有現在流行的物件導向分析與設計，即OOA和OOD

其實無論是哪種方式，商務邏輯的實現基本上分為一個靜態表示，和動態行為了。

如請假申請

則是要建立一個請假單的實體（或對象），在建立過程中，可能通過程式控制其商務規則的實現，如必須填寫請假開始和結束日期。

建立的這個請假單，原則上是永遠存在於這個系統了（當然是在沒刪除的情況下），然後只要你看到一個這樣的對象或一筆這樣的資料，你就能通過這個對象知道當初某某某寫了這樣的一張請假單，這就是這個請假單實體（或對象）所代表的意義。也即商務邏輯的靜態表示。

與之對應的就是動態行為了，通過系統的運行（經常是人與系統的互動），這類邏輯得以隱含實現，如

系統拒絕了一個訪問者對於他沒有許可權的請假單的查看請求。

系統將一張事假超過了20天的請假單送給了總經理審核。

系統授予了總經理在登入之後審核特殊請假單許可權的許可。

 

對於這些邏輯的實現，系統一般不會留下痕迹，但它確實做了這部分工作。

  

無論是區分底層架構還是識別各種各樣的商務邏輯，一個終級目的--就是為了重用。

只有重用才讓我們的工作變得有意義起來。

 

將商務邏輯中關於許可權的需求提取出來，提供一個可重用的許可權解決方案。

將商務邏輯中的流程部分提取出來，提供一個通用的工作流程方案。

將商務邏輯中對於資料的驗證提取出來，提供一個通用的驗證方案。

將商務邏輯對於多國語言的要求提取出來，提供一個通用的多語言解決方案。

將商務邏輯對於UI的相同或相似要求提取出來，提供一個通用的UI解決方案。

等等。。。

 

從底層架構到通用的商務邏輯解決方案，這些工作做得越多，具體系統開發時就會做得越少，這其中如何把握平衡，則是系統架構者的能力體現了。