簡議使用業務模型驅動進行軟體的設計

 

在我工作的這些年裡，前幾年做的大多項目都是資料庫驅動型的，我想很多人也都是這樣的。對於資料庫驅動型的項目，我們的核心都是圍繞資料庫在做開發，通常我們都在寫CRUD的代碼，後來有了代碼產生器、ORM，我們的工作是變的更少了。但是大家有沒有覺得，雖然自己一直在使用物件導向的語言在做開發，但是通常我們使用物件導向進行設計的能力並沒有多少的提升。最近幾年我脫離了做以資料庫驅動為主的項目，來到了一個陌生的領域，剛開始的路很難，因為你要從需求抽象出系統的業務模型，而業務模型設計的對錯將直接影響到系統的穩定性，可擴充性等等，這才是我覺得 軟體設計師 的工作。

後來我遇到項目，我大體會用業務對象進行建模，而業務對象的計算所使用的資料，則根據業務對象的特點進行擷取或儲存。這使我豁然開朗，在這些的設計過程中，開始理解設計模式的好處，開始以全域觀的角度去看待系統。你的視角提高了，那麼對於系統使用什麼樣的資料庫，使用什麼樣的訊息佇列，使用什麼樣的緩衝的這些問題，你會覺得其實這些問題只是為了能夠充分發揮業務對象的能力，其核心還在於業務對象上。對於計算強度大的業務對象，可以為其設計多線程的，多進程的，亦或是分布式的。一切的一切都以業務為核心，把業務對象為系統內的一等公民，我覺得這才是基於物件導向的設計與實現。

再回過頭來看資料庫驅動型的項目，也可以使用基於業務模型驅動的設計進行重構。通常我們做基於DB的項目，通常是先建立了DB，再通過代碼產生工具產生代碼。對於ORM（對象關係映射），也只是解決了你不用以結構化查詢的角度去構造SQL語句，再對返回的結構化資料進行轉義成對象的工作。這有存在一個很大的問題就是DB的設計與真實系統的業務對象往往有時候很難融合。在這種情況下，我們的業務對象在設計的時候，不得不照顧DB上的設計。否則業務對象的資料儲存將是一個很大的問題（至少不會那麼順手）。其實我覺得正確的做法應該是：先分析系統的核心業務模型，在業務模型確定的情況下，在確定什麼樣的業務對象的資料需要持久化。在這個基礎上為業務對象的資料持久化再設計如何儲存資料。當然了資料庫也有資料庫的好處，對於資料量大的查詢和曆史資料的儲存使用DB還是不二的選擇。

在最近的一次項目中，由於項目的負責人偏硬體，對軟體瞭解的比較少。在需求文檔還未成型的時間，就讓我先設計系統的資料庫結構，這使得我很苦惱。在不得已的情況下完成了工作，隨著後面的業務模型的建立，我發現存在一些資料庫物件我沒法使用，我不得不為領域模型再一次的建立資料對象類，通過新的資料對象類通過一些契約的方式去調用基於資料庫產生的資料對象類來完成讀取和儲存工作。當然了，你會問我，為何不重構資料庫結構。問題是，項目裡負責UI的工程師的習慣還是比較傾向與以DB為驅動的，所以......。像這樣的問題我估計會是很多數，很多人還是習慣以資料庫驅動的方法去完成工作。

設計步驟

1 接到需求後，先通過和熟悉當前領域的工程師進行確認系統中的領域模型；

2 對領域模型進行建模，之間也需要和領域工程師進行多次的確認，以獲得一個雙方都認可的領域模型；

3 根據領域模型，設計出系統的業務模型（類）；

4 實現業務模型和測試；

對於業務模型的資料儲存問題，可根據不同的業務模型性質和系統需求進行不同的持久化儲存；

通常的儲存有：

A 記憶體

B 檔案（一般檔案、結構化檔案、關聯式資料庫、非關聯式資料庫、隊列 等）

通常業務模型是整個系統中的核心。通常客戶的需求會改變，所以我們的UI在使用業務模型的時候，都需要基於業務模型的介面進行編程。通常我會使用簡單類工廠或IOC 容器去處理對象的建立以及對象間的依賴關係；而對於系統中的其它方面，比如：日誌，許可權等，我會通過AOP的方式注入業務模型中，這樣使得我們的工程師將核心精力放到業務模型的實現上。

在以業務模型為第一公民的設計理念上，所有的其它操作都要圍繞業務模型，比如對於業務模型的資料儲存上，我們持久化的方式就有很多的選擇，可以根據業務模型的資料特點，選擇不同的資料儲存方式。對於簡單的非系統全域化的業務對象，它的資料可以儲存以一般檔案或結構化檔案的方式進行儲存。而對於系統全域化的業務對象，這些資料可以儲存到資料庫中。