由於 interview ont pos 面向 trac height amp style

原文:http://www.infoq.com/interviews/Technology-Influences-DDD#

要實現DDD(domain drive design 領域驅動設計)原始意圖，必須CQRS+Event Sourcing。

CQRS+Event Sourcing事實上不可是一種全新思想。將可能顛覆Java或C#現有的編程體系。

使用傳統JavaEE或Spring + Hibernate這種框架，是無法實現DDD原始意圖的，這個DDD創始人Eric Vans已經說過：2012年Eric Evans關於技術怎樣影響DDD的會話

提供基於Jdonframework實現的CQRS 源代碼，ES部分略微拓展一下就可以：Robot.rar。文章見DDD DCI和領域事件

或者選用新的編程語言Scala，文章：Scala的event-sourced和CQRS案例代碼

有人說，我一定要用Spring來實現，那麽會導致什麽後果呢？
由於Spring不支持Domain Event，僅僅能將外部接口直接註入到領域模型。非常多接口會汙染領域模型，最後領域模型還是被外幣接口或架構綁架了。

這嚴重違背DDD中聚合根是語言核心，編程代碼必須反映統一語言
這個重復重申的要旨，難道我們重申這個僅僅是理論喊口號嗎？假設它不如此具有顛覆性，我們重復強調它幹嗎？假設不是由於如今所謂經典做法全然違反這樣的要旨，我們苦口婆心地說它幹嗎呢？

當然，該PPT也去除了Hibernate等ORM註解。由於它也嚴重綁架幹擾了領域模型，幹擾領域模型如實成為統一語言。

所以。雖然Jdon兩年前就在討論DDD CQRS ES，而且也推出這種開源框架，這些都是一種探索，是不是代表未來不能確定，可是假設這是未來。我相信這是JavaEE或Spring必須跟上的，可是Java C#語言本身帶來的限制，還是不如新語言Scala等要優雅。

雖然jdonframework使用Disruptor實現了領域事件，也是通過領域模型的註入實現，雖沒有Scala的Actor那麽直接，可是性能和簡潔不亞於Actor。

假設各位有意在自己項目中實施DDD，並且不改用框架，那麽出來的效果會非常差，還不如本文開始批評的貧血模型，把業務方法都放入Service中。

假設你對JavaEE

認識或面向對象設計OO不夠Strong。那麽也請不要選擇DDD。你遇到的概念和思路轉變不是象學習一門語言那麽簡單，項目有風險，實施需慎重。

另外一篇文章可讀 http://www.jdon.com/44491

[外文理解] DDD創始人Eric Vans:要實現DDD原始意圖，必須CQRS+Event Sourcing架構。