需求分析之業務模型

標籤：

資料和事件分開

先從Peter的資料和事件分開說起，Peter找了李福華討論了返運的需求實現，他的建議是將庫存和返運關係分離開來，即資料和事件分離開來：不要讓（事件）狀態汙染資料，對於正常入庫、調撥入庫這屬於原生態狀態（Native Status）沒問題，對於返運這種後天事件導致的狀態就不要用來汙染資料，而是單獨頁面承載操作，單獨表結構來儲存狀態；我是深以為然；如果這樣，出庫是否也應該分離出來呢？庫存表是否只是儲存庫存資訊，表明庫存還有多少多少，也屬於"Native Status"，我倒是覺得沒必要分離。

需求三板斧

核心對象都是什麼，核心對象欄位都有什麼（客戶提供，還要考慮關聯欄位）；業務對象間關係都是怎樣的（二元關係如何1:1還是1：*，通過什麼進行關聯）；和業務外對對象關係是怎樣的；商務程序是怎樣的，都有哪些"約束"；該業務的目的以及產生的對象後續影響有哪些（產生的資料將會被怎樣使用）；

什麼是業務模型

杜工在周會上面提出了對於入庫資訊而言，調撥、正常入庫其實是並列的；但是我們現在是把內容都捏在了一起，還沒有加以區分，比如批次號，對於調撥以及正常入庫其實是允許他們重複的；但是我覺得這個業務模型漸漸的有了意識，就是分類流程，當然在資料庫實體儲存體上可以放在一張表裡面，但是在理解和規劃的時候，一定要有一種劃清楚各個獨立主題的概念；

業務由兩部分組成：資料和過程。業務的結果是資料（核心資料），業務的過程卻是獨立的，比如入庫包含調撥的業務和正常入庫的業務，發放控制的出庫以及調撥的出庫，儘管他們都是入庫/出庫（在實體儲存體結構是一致的），但是他們確實並列的，彼此平行的，這在實體儲存體上的表現就是通過一個欄位來做區分，業務層（Application層）處理上卻要各自分開，保持彼此的純潔性。

這意味著，回到了之前考慮，對於任何功能點要"認祖歸宗"，一定要找到一個歸屬的大類（如果確實沒有，那麼就建立一個）；然後再大類下面尋找並行同類；這樣在邏輯上（模型）做到了分離，在代碼實現以及資料庫設計上面也彼此獨立，做到了比較好的"乾淨"的關係，正所謂"君子群而不黨"。

那麼，就出來的，業務模型本質其實是針對業務的"過程"部分，針對過程進行歸大類，分離出獨立過程單元體（Dependency Process Unit，DPU），並針對每個獨立的DPU進行生命週期設計，這就是業務模型的建立

?

?

需求分析之業務模型