DDD專案現在實施的問題

banq發表於2012-12-18
CQRS+Event Sourcing其實不但是一種全新思想，將可能顛覆Java或C現有的程式設計體系。

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

要實現DDD原始意圖，必須CQRS+Event Sourcing。

提供基於Jdonframework實現的CQRS 原始碼：
為幫助大家更好理解本PPT，用Jdonframework將Match原始碼完整寫成可執行的專案：

Match完整原始碼按這裡

也可以透過打包下載：example.rar

內中含有DCI+CQRS和CQRS+EventSourcing兩種案例。

其他案例：
（1）選用新的程式語言Scala，文章：Scala的event-sourced和CQRS案例程式碼
（2）Axon的Axon-trader案例

有人說，我一定要用Spring來實現，那麼會導致什麼後果呢？
因為Spring不支援Domain Event，只能將外部介面直接注入到領域模型，很多介面會汙染領域模型，最後領域模型還是被外幣介面或架構綁架了，這時被綁架的領域模型就成了扁平的“資料”，而不是活生生的“語言”。

這嚴重違背DDD中聚合根是語言核心，程式設計程式碼必須反映統一語言，這個反覆重申的要旨，難道我們重申這個只是理論喊口號嗎？如果它不如此具有顛覆性，我們反覆強調它幹嗎？如果不是因為現在所謂經典做法完全違反這種要旨，我們苦口婆心地說它幹嗎呢？

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

所以，儘管Jdon兩年前就在討論DDD CQRS ES，並且也推出這樣的開源框架，這些都是一種探索，是不是代表未來不能確定，但是如果這是未來，我相信這是JavaEE或Spring必須跟上的，但是Java C語言本身帶來的限制，還是不如新語言Scala等要優雅。儘管jdonframework使用Disruptor實現了領域事件，也是透過領域模型的注入實現，雖沒有Scala的Actor那麼直接，但是效能和簡潔不亞於Actor。

如果各位有意在自己專案中實施DDD，而且不改用框架，那麼出來的效果會很差，還不如還是使用本文開始批評的貧血模型，把業務方法都放入Service中。這種號稱SOA架構也就是面向服務的架構很容易將服務做出程式導向的大函式，擴充維護性都很差。

如果你對JavaEE認識或物件導向設計OO不夠Strong，那麼也請不要選擇DDD，你遇到的概念和思路轉變不是象學習一門語言那麼簡單，專案有風險，實施需謹慎。

[該貼被banq於2012-12-19 13:45修改過]

相關文章