企業級業務系統開發我們略過需求的采集、分析，直接進入設計。
領域驅動設計（DDD）是近10年流行、比較成熟、比較成功的軟件設計方法、理論。我們早期常見的軟件開發方式是拿到產品需求后，直接考慮數據庫中表應該如何設計，這種方式已經將設計與業務需求脫節，而更多的是直接考慮應該如何實現了，這有點本末倒置。而DDD是從領域(問題域)為出發點進行的設計方法。
這里先說一下領域驅動設計的概念：是一種以領域為核心的設計方法與理念。建立正確的領域模型是領域驅動設計的核心。
我的理解：
DDD(領域驅動設計)是一種設計方法，它是通過捕獲與分析產品需求的領域概念，然后將這些領域概念設計為領域模型，領域模型從本質上反映了產品需求。通過領域模型作為指導，最終作為軟件代碼的依據。DDD中包含了大量成熟的方法、模式和架構，DDD這種設計方法或理論比OOD等設計方法更靠近產品的需求，也更靠近編寫的軟件代碼。這里需要重點說明的是：
1.產品需求！=用戶需求：用戶需求是用戶站在自己角度描述的系統能夠完成的功能，通常只能是需求分析師進行需求采集的產物，而產品需求是通過分析用戶需求后形成的用戶本質的需求，通常的表現形式是“需求規格說明書”或“四色原型模型”。另外領域模型應該關注的是領域核心的概念，而不應該過多的考慮將用戶如何納入領域模型中。
2.領域模型是對某個邊界上下文的領域的表示，是反映了產品需求的本質。
3.領域模型應該包含領域的業務邏輯，這樣可以提高業務的可理解、可維護、可重用。DDD一般建議領域模型為充血模型，也就是一個領域模型除了包含狀態，還應該包含自身業務的行為，不應該是只包含POCO，而不包含行為的貧血模型。我個人認為不應該簡單的認為應該建立貧血模型還是充血模型，而是模型應該是能夠包含自身的狀態，並且能夠維護自身的業務規則。
4.領域模型只考慮業務，與技術無關。我認為與技術無關只是說明領域模型關注的重點是業務，而不是技術，但是在領域建模時，還是要考慮到技術方面的實現，比如性能等。
5.通用語言。在需求分析和設計的過程中，用戶、領域專家、開發人員溝通應該采用一種通用語言。這里說的通用語言我認為主要表示兩個含義，一是對領域中的一些概念應該明確，並使用這種明確的語義進行交流，二是最好在一個領域模型上進行需求與設計的討論。但在中國好像第二種方式比較困難，一種原因是中國的用戶不習慣，第二種原因是開發人員不希望用戶直接看到模型。
6.有了DDD的一些模式、架構以及領域模型后，設計可以平滑的實現為軟件代碼。
7.在設計與實現的過程中，用戶、領域專家、開發人員會不斷交流，會對領域模型進行不斷的細化、完善。另外需要注意的是，代碼的實現必須要依賴於領域模型，如果有偏差，要么調整代碼，要么是原來的領域模型不夠完善，需要調整領域模型。
8.領域模型是整個軟件的核心，是最有價值的部分。
歡迎加入QQ討論群：309287205