前言
領域驅動設計最近貌似開始火起來了，越來越多的人開始認識到領域設計的重要性，從我做過的項目來看，似乎歐洲已經有很多的公司開始實施領域驅動設計了，我看領域驅動設計也有些時間了，但是網上不管是文章還是代碼，都顯得太過“高大上”，一談領域驅動設計，一大堆的概念一股腦的給你上上來，搞的有點暈頭轉向，而我想在一些中小項目實施領域驅動也遇到了不小的障礙，大家對很多東西都處於一種恐懼的狀態，而且在正真開始實施時，也遇到一些疑問，所以也想和大家交流學習，因此開始在此寫寫對領域驅動的理解，后面會有一些輕量的演進代碼。
為何要領域驅動設計？
簡化數據存儲
領域驅動設計有很多原因，談到我為啥要在公司推行領域驅動設計，說起來還是很好玩的，因為原來基於數據驅動的開發方式，也就是傳統的多層開發架構，大家定義了一堆DAL來操作數據, 在.Net大家一般有兩種使用方式，一種是用ORM像Entity Framework, 另一種想使用Dapper這樣輕量級的Mapping工具，這些都要把關系型數據轉換為對象。結果導致以下幾種結果。
- 沒有正確的使用ORM, 導致數據加載過多，導致系統性能很差。
- 為了解決性能問題，就不加載一些導航屬性，但是卻把DB Entity返回上層，這樣對象的一些屬性為空，上層使用這個數據時根本不知道什么時間這個屬性是有值的，這個是很丑陋的是不是？
- 如是又開始使用一些輕量級的數據方法，比如使用Dapper然后自己寫SQL語句，這本來是很不錯的方式，但是大部分人的SQL能力實在不敢恭維，大部分寫出來的SQL語句，甚至比EnityFramework生成的語句還差。
所以，我就想我們做項目，大部分處理的應該是業務，如何讓程序員從數據存儲，模型轉換的大泥潭里解放出來，領域驅動設計就進入了我的視線，當然光從數據這個角度還不足以選擇領域驅動設計，用一個NoSQL數據庫是不是就解決了？ 但是NoSQL也有一些問題，比如MongoDB如何更優雅的保證事務以及數據的一致性等。
更多了解上下文
我們很多軟件的問題，大家都知道是需求的問題，也就是客戶的需求我們很難理解准確，導致程序員更加關注"HOW" 而忽略了"WHAT", 最終做了幾個禮拜甚至更長時間，結果客戶會說:"What?! I told you", 但是客戶告訴我的，我們理解是不一樣的。比如客戶說：“ Great job, I love you!” 這個Love肯定不是男女之間的Love, 我們拿到的是一個客戶的需求，他的上下文是什么？ 比如說：“這個球打的好”， 如果是在打籃球，肯定說的事籃球，如果是在打乒乓球肯定說的是乒乓球。 而領域驅動設計里我們可以讓業務人員更多的參與系統，更早的參與系統。
統一語言(Ubiquitous Language)
業務人員和我們使用一樣的語言，我們的程序比如讓業務盡量集中在領域里，比如在傳統的數據驅動里，如果說Jack愛Rose, 我們一般會這么寫
UserService.Love(Jack, Rose)
但是我們業務人員很奇怪誰Love誰？ 為什么要UserService?, 如果我們寫成下面這樣
Jack.Love(Rose)
還有如果我們用
Company.hire(employee)
來代替
companyservice.hire(company,employee)
這樣我們就更容易讓業務人員參與進來，而且代碼可以更易於表示真實的業務場景。