寫在前面

對於領域，業務，業務模型，解決方案，BC，領域模型，微服務這些概念經常分不清，但是這些知識在進行領域建模及DDD落地過程中又比較重要。

領域，業務和業務模型

• 領域：問題域，問題空間，領域是一種邊界，範圍，一個領域往往代表了一個問題域的邊界，業務範圍越大，領域邊界就越大。
• 領域圍繞業務建立邊界，因為業務不同，所以也存在領域的大小和領域劃分，劃分出來的領域成為子域，每個子域對應一個小問題或小業務，因重要性不同又劃分為核心子域和支撐子域。
• 業務往往對應一個業務模型，從業務本身出發，分析業務邊界範圍內的各種業務場景，及業務概念之間的關係。得到業務模型最常用的方法是名詞動詞形容詞分析法，還有比如四色原型分析，找到一個適合自己的，業務模型提煉了業務核心概念及其關係，可以幫助我們更好理解業務本身。

解決方案

進行DDD實踐時，回進行需求分析，領域劃分，領域建模等工作，系統落地則需要一套解決方案，如果實現一個電商平臺，需要一個複雜的系統解決方案，如果方案設計的過大，各模組，元件柔和在一起，就不利於整個系統維護-演進-伸縮等需求。所以需要對解決方案進行拆分，成為一個個獨立的小的解決方案。

領域代表問題域，解決方案代表解空間

解決方案的拆分往往沒有捷徑，還是需要經驗，對系統的熟悉程度等情況。利用軟體設計的各種原則，最佳實踐，設計模式，非功能特性需求，及團隊情況來指導我們解決方案的拆分和落地。

拆分有時可以從效能角度切入，有時可以從業務角度切入，有時可以藉助CQRS，或者伸縮性角度考慮，找到適合自己團隊和專案本身情況，最合適的就是最好的。

BC

BC作為界限上下文，是DDD的核心概念，有Bounded和Context兩個概念，一個場景糾纏多種上下文，是一個時空感的概念。 通過上下文邊界可以對邊界內的領域模型進行物件概念的明確，如果沒有這個上下文邊界，同一個概念可能存在歧義，理解上產生偏差。比如商品在商品中心的BC中是聚合根，而在訂單的BC中含義不同，只是一個值物件。

領域模型

領域模型是DDD中的核心概念，是業務拆分，軟體設計的綜合結果，任何一個領域模型，都是在特定的BC邊界內才有意義。

業務模型是對業務概念及其關係的表達，領域模型在業務模型基礎上，採用OOA/D的思想進行進一步抽象的設計模型，領域模型中有聚合，實體，值物件的區分。多個業務模型可以雜糅到某個領域模型之中。

進行領域建模大致的過程：

• 得到業務模型
• 運用軟體設計思想和原則對業務模型進行模型提煉

微服務

微服務出現之後，對於微服務的劃分和DDD中BC有很大的契合點，有相同的探尋邊界的原則。

總結

• 領域=問題域=問題空間=業務邊界
• 每個業務的問題都可以推匯出一個業務模型
• 領域拆分，業務建模，是需求分析階段需要做的事情
• 解決方案的拆分，領域建模，是軟體設計階段該做的事情
• 解決方案的邊界就是BC
• BC邊界契合微