業務背景

幾個月前,我參與引導了一個大型通訊企業某個技術團隊的DDD實施過程。這個團隊的主要業務是通過底層通訊設備內置的探針不斷採集海量數據,然後進行一系列的數據操作,從而對網線網路站點等網元進行評估與優化,同時包含一些網路規劃的功能。覆蓋的網路場景包括覆蓋分析、話務分析、用戶分析、高鐵評估 、業務質量管理、客戶感知保障、商業智能支持等。底層通訊設備採集的數據量非常巨大,基本上都是以GB為單位,這與以往的作業類系統不同,是一個典型的以數據處理分析為主的系統。項目類型上的不同也導致後面在DDD建模過程中,遇到了一些以往沒有遇到過的問題。

建模過程

經過與客戶的討論,我們初步選擇了樓宇分析這個業務領域進行試點建模。

在《DDD實施過程中的點滴思考》這篇文章裏我也提到,我一直想在建模開始的時候就把業務問題域梳理清楚,明確核心域,通用域和支撐域;然後就核心域進行建模,接著把模型放回核心域驗證是否能解決業務問題。所以這一次,我一上來就先使用名詞動詞法對業務進行梳理。一般來說,名詞動詞法就是讓客戶通過簡單的幾句話描述業務要解決什麼樣的問題,然後注意其中的關鍵名詞與動詞。

名詞動詞法

通過名詞動詞法梳理的業務領域如下:

樓宇分析業務領域梳理

由於某些詞語涉及到客戶信息,所以被mask了。總體來說,通過這種方法,能把某個業務下的細分場景捋清楚,但這不是最關鍵的,最關鍵的是當把細分場景梳理出來後,對核心域,通用域,支撐域的識別與區分。這非常重要,因為傳統意義上來說,DDD認為核心域代表了產品的獨特的核心競爭力,團隊只應該對核心域進行建模,並把主要精力投在覈心域的開發工作上,而對於通用域與支撐域,DDD主張通過購買或者外包來實現。具體的識別過程,需要客戶的領域專家一起參與討論。但是實際上,在之前的項目過程中,我們還是會把其餘兩個域的模型都建了。這次也一樣。

按照傳統套路,當核心域識別出來後,後面就是事件風暴大法了。

樓宇分析事件風暴

熟悉事件風暴的同學可能就已經看出與標準的事件風暴有什麼不一樣了。「數據模型」這個概念在標準的事件風暴裡面是沒有的。那為什麼這裡會出現這麼一個概念呢?按道理說,事件風暴完了後,就應該是識別聚合了。問題就出現在這裡。當時我們發現,根據以上事件流無法識別聚合。因為聚合的一大特徵是它是有狀態的,而在這個場景下,事件流裡面的都是沒有狀態的數據。做過大數據或者數據分析類項目的同學可能清楚,這類項目對數據的處理就是數據採集、解析、清洗、拼接、過濾等步驟,在這個過程中,數據是沒有狀態的,可以認為每一步產生的數據都是全新的數據。因此這裡再沿用傳統的聚合概念就不合適了。所以這類我們引入了「數據模型」這個概念。可以認為,數據模型就是數據分析類項目裏的「聚合」。

基於這個共識,我們可以往前再走一步,整理一下數據模型的事件與命令,

樓宇分析數據模型與聚合

這裡區分了數據面和控制面。數據面主要負責對數據的處理流程,控制面主要是傳統作業,負責控制層面的工作,所以它會出現傳統意義上的聚合。例如圖中的「特徵庫構建任務」。

建模到這一步,下一步應該就是限界上下文了。但是,這裡我們先不著急。由於事件流裡面流動的是數據模型,所以事件流即數據流,我們何不看一下數據的流動呢?所以我們基於數據流再梳理了一次:

樓宇分析數據流建模

這一下數據的流動就清晰多了。然後下一步才做的限界上下文:

樓宇分析數據模型限界上下文地圖

我們把限界上下文投射回最開始時通過名詞動詞法梳理的業務領域,驗證是否能解決業務問題。這一步同樣需要業務領域專家一起討論。

後記

後面因為某些原因,項目終止了。我們的建模工作也結束了,沒法再繼續驗證模型的可用性。但是還是把樓宇分析業務場景的建模基本完成了,後面其實就是實現域的事情。 在實現層面,客戶熱衷於微服務,但坦率來說,微服務架構是否真的適合這種數據分析類項目,我個人是持保留意見的。把微服務應用於GB級的數據傳輸,可想而知挑戰有多大。

說回這次建模。通過這次建模得到的模型是否能很好的指導後面的實現落地,這很難說。畢竟把DDD應用於大數據或者是數據分析類項目的建模,我還是第一次做,業界做的也不多。方法論需要更多的項目來整理,提煉與驗證。通過這次建模,我的總結如下:

1. 建模前通過某些方法(如動詞名詞)把業務領域梳理清楚是可行的,這可以避免得到解決方案再來反推問題域的尷尬。我們要做的只是把解決方案投射回業務領域驗證就行。

2. 對於大數據或數據分析類項目,可認為數據模型即聚合。

3. 事件風暴或許並不適合這類項目,可能基於數據流建模的方法更合適。如果還有類似的項目,可能我就會直接基於數據流建模了。當然這個需要更多的項目去提煉驗證。

4. DDD完全適合於這類項目,只是具體的落地方法可能需要調整。因為DDD的核心理念是業務領域驅動架構設計,任何系統架構都必須隨業務架構演進。借用我從EA培訓聽到的一句話,無業務不IT,無架構不解決方案。套在DDD上,就是無業務領域不架構設計。

文/ThoughtWorks 馮文輝


推薦閱讀:
相關文章