實例實戰! 領域驅動四色建模法分析需求

領域驅動和微服務的關係

自從微服務火了之後,如何去劃定微服務的界限成了團隊一直討論不休的問題. 界限大了,一個庫裏面十幾張表,又變成了以前的單體應用,界限小了, 一個微服務裏面就一個方法, 然後還要用一個Jvm去跑

這時候,我們就可以用領域驅動來解決微服務界限劃分問題,一個微服務代碼一個領域,這樣是再好不過了

領域驅動和以往的需求分析方法的不同

以往的需求分析:

前面先畫用例圖, 數據流圖,時序圖等, 這些確定下來之後,然後就開始建表,然後看這些數據應該怎麼存,然後怎麼取,然後再怎麼操作,能完成這個用例功能.

領域驅動的需求分析:

一堵無限長的牆,一盒便利貼, 然後大家開始集思廣益,想一想我們系統中會發生事件(代表的是狀態, 不是動詞),今天我們以現在正在開發中的小程序:湊心為例, 這是一個可以匿名問答的小程序,那麼它裏面的事件就有, 問題已創建,答案已創建等等

領域驅動中的主要概念:

用以分析的案例:

小程序:湊心, 匿名問答, bring heart togather!

事件,命令,實體,補充信息

即然有了事件,那麼就會有產生事件的源頭-多條命令共同作用的結果.我們還是以問題已創建為例,先刷新名字,再輸入問題,點擊發送. 這三個命令產生了問題已創建的事件. 在第一步刷新名字時, 因為我們系統會默認給一個名字,所以這裡可以加一個補充信息, 刷新名字(系統會隨機默認一個)

事件有源頭,也會有結果,如上問題已創建事件,就是產生一個問題實體

這樣,我們就把下面四色建模法,對應的概念給梳理出來了

四個顏色代碼,下面這個顏色分類,

用藍色表示命令,用紅色表示實體,用綠色表示領域事件,用黃色表示補充信息

於是,上面我們創建的問題,就可以做如下表述

在問題之後,我們可以對答案也做類似分析

還有我們的用戶信息,因為我們是全匿名的,所以進來之後,只獲取一個openID,沒有獲取手機號,也沒有獲取微信等信息

通過上面對事件,命令,實體的整理,我們把相關的實體整理到同一個領域中,這樣就完成了使用DDD的四色建模!