前面2篇DDD入門之理解面向對象(一）, DDD入門之解決了什么問題（二） 已經說明了為什么要使用DDD，現在來看一個具體的例子：
明確需求
業務需求
假設我們要實現一個商品中心這個核心領域。要求如下：
- 商品包含一個或多個明細。一個明細也可以被包含在多個商品里。明細有三種：在線課程、實體書、線下服務。明細不可單獨售賣，但可以單獨編輯
- 商品和明細都有類目
- 商品的類目和明細的類目可以保持一致，也可以不保持一致
- 明細在不同的商品中可以有不同的價格
- 商品的價格是各明細的價格的總和。商品的價格不可修改，可通過添加優惠券實現減價。
- 在線課程的有效期分兩種：截止日期，下單后xx月。
- 商品有狀態，必須是上架狀態才可以售賣，上架后不可修改
- 商品要審核后才能上架，因為商品內可能有違規的圖片、文字，所以必須要經過法務審核
構建模型
1.商品在其生命周期內是可修改的，且有唯一的標識，很明顯是個實體。並且，商品是跟外界交互的入口，它是一個聚合根。
2.課程有唯一的標識，可被修改，雖然它被包含在商品內，但是它可以單獨編輯。一個商品被下架了，但是這個課程在其它商品里仍然可以被售賣。它的生命周期是獨立的，所以它也是一個聚合根。
3.實體書和線下服務同理，也是聚合根。
4.優惠券比較特殊。它有自己的生命周期。如果優惠活動很多，也很復雜，應該將優惠拆分成一個單獨的支撐領域。這樣優惠可以做的很復雜，比如弄一個規則引擎來配置各種優惠券。這里我只做一個實現DDD的demo，不搞那么復雜，暫時不考慮優惠。
5.審核也比較特殊，它應該是一個通用領域。這里不考慮審核。
實現模型
需要數據庫設計嗎？ 個人認為不需要了。還記得hibernate的ORM和自動建表的功能嗎？曾經我們對hibernate棄如敝履，現在回過頭來看，也許我們用錯了。
我們總以為Hibernate自動生成ddl的功能很雞肋，那是因為我們太習慣於先建表，后寫代碼了。我們一直以為數據庫設計是基石，只有把數據庫設計好了，才能可靠地實現業務。人家DDD根本不是這么玩的。 先設計數據庫，開發人員跟業務之間就被這個數據庫的表結構給隔離開了。其關系是： 業務 <--> 數據庫 <--> 開發。
DDD的玩法是： 開發 <--> 業務 <--> 倉儲（數據庫），看到區別了嗎？這種玩法是直面業務。DDD好玩的地方就在於：
真正的程序員敢於直面復雜的業務！
我知道大家嫌棄hibernate，很重要的一個原因是關聯表查詢的時候很難受。一提到這個大家都感同身受。現在為什么我改變主意了呢？因為實現DDD的時候可以采用CQRS（讀寫分離）架構。這樣一來，在寫數據的時候只需要少量簡單的查詢即可，復雜的查詢放在讀模型里，讀模型不需要跟寫模型保持一致，讀的時候可以選擇原生的SQL，Mybatis，或者NoSQL，再也不用擔心配置復雜的一對多，多對多等問題了。
據我所知，.Net的小伙伴比較熟悉DDD，可能是.Net有一整套DDD的框架吧。有人說Java用了Spring框架，天生的只能用貧血結構。因為實體里沒有save,update等方法，所以是貧血的。這種說法是有問題的。原因我在DDD入門之理解面向對象(一）這篇文章里已經說過了，這里不再贅述了。 如果有不同看法，歡迎留言討論。DDD最有爭議的就是這個“貧血”和“充血”模型了吧。
我打算用Spring Boot + JPA寫一個DDD的demo。Spring Data JPA 默認就是Hibernate實現的，本系列文章JPA就是指Spring Data JPA, 具體的ORM框架就是Hibernate。