領域驅動設計(DDD)對開發者來說是面向對象設計的自然進化 總的來說DDD包括兩個部分: 分析部分通常是由開發人員去和領域專家溝通業務知識,但是開發人員和領域專家是有代溝的, 為了簡化溝通成本,這時統一語言出場,統一語言是項目各方共同使用的辭彙表, 在溝通業務知識,又或者叫溝通需求階段,開發人員需要 ...
領域驅動設計(DDD)對開發者來說是面向對象設計的自然進化
總的來說DDD包括兩個部分:
- 分析部分
分析部分通常是由開發人員去和領域專家溝通業務知識,但是開發人員和領域專家是有代溝的,
為了簡化溝通成本,這時統一語言出場,統一語言是項目各方共同使用的辭彙表,
在溝通業務知識,又或者叫溝通需求階段,開發人員需要不斷的完善這個辭彙表,隨著對需求的深入瞭解,
你發現某些名詞存在多重含義,這種情況一般預示著多個子領域的出現,
(邊界上下文)Bounded Context是DDD用來指代獨立領域區域的術語,有一個子領域就有一個邊界上下文,
邊界上下文之間通常相互關聯,這種關聯關係在DDD里叫做上下文映射,它為正被設計的系統提供一個全面視圖,
DDD里存在以下五種關聯關係(防腐層,從屬,客戶供應商,搭檔以及共用內核)。 - 策略部分
一旦分析部分結束,分析部分就可以產出多個邊界上下文之間的映射關係(即上下文映射),有了這個系統的全局視圖,
我們就可以為每個邊界上下文確定合適的架構,是的策略部分的任務就是評估各種架構方案以及為每個邊界上下文選擇架構,
比如是使用web form ,asp.net mvc 還是分層的領域架構 又或者是簡單的CRUD,
這裡有一個通用的指導原則就是你要寫的軟體的使用期限,就是說如果你只是做一個輔助工具,而且只用一次,
那麼你真的沒有必要把他複雜化,相反如果你要做一個淘寶系統,那麼還是考慮下DDD吧。