2009-08-18 147 views
3

我正在考慮實施領域驅動設計方法(類似於here中描述的方法),但希望將其與Doctrine ORM集成。有沒有人做過這樣的事情?我的初始本能就是使用Doctrine作爲DAO層,但對於Doctrine來映射我的數據庫字段,我的實體對象映射到Doctrine對象上的(基本上)相同的一組字段似乎有些複雜。使用領域驅動設計原則

我最初的目標是將我所有的DQL /查詢邏輯從我的域實體中分離出來,但現在我在設計模式域中感覺有點迷失。

我知道Doctrine 2應該提供更友好的方法來DDD技術,但我不知道我想等那麼久。我想做什麼是有意義的,還是應該找到另一種方法?

謝謝。

回答

2

在我看來,由於缺乏Repository類,所以學說在DDD方面並不完美。 Doctrine支持表格數據網關和活動記錄等模式,雖然對於某些問題的良好模式不一定是「經典」DDD的最佳選擇。但是,您可以解決這些缺陷。

一種選擇是從Doctrine_Table派生出來,並將其用作窮人的存儲庫。例如,如果您有一個名爲「BlogPost」的類,則可能有一個繼承自Doctrine_Table的表類「BlogPostTable」。然後,您可以將諸如'findByCategory'之類的方法添加到BlogPostTable類中,使這些邏輯與您的域對象(從Doctrine_Record繼承)保持分離。它與'純粹'DDD倡導的模式不完全相同,但它足夠接近。

即使沒有完全相同的設計模式,您仍然可以使用DDD的核心洞察力。最主要的是無處不在的語言,這個概念試圖用領域專家和開發人員都能讀懂的精確語言來描述你的領域。

+0

謝謝。我認爲這個迴應完全反映了我的經歷。學說的方格釘恰好不適合DDD的圓孔。我最終將我的Doctrine_Record類視爲我的實體,並使用Doctrine_Table作爲DAO層實現了一個基本的Repository類。雖然它確實給了我想要的大部分分離,但它確實感覺有點笨拙,或者架構過度,因爲有時存儲庫感覺有點多餘。 – 2009-09-02 02:16:30

+0

偶然發現Google的這個答案,並認爲值得注意的是,現在已經過時了,因爲Doctrine2實現了數據映射器模式,實體是POPO的,因此它非常適合DDD並且非常適合SRP。 – 2015-08-20 13:08:46