這是一個一直在困擾着我一段時間關於DDD的東西。在處理技術人員與非技術領域專家之間需要複雜模型和大量互動的非技術業務領域時，我可以清楚地看到這種方法的好處。域驅動設計 - 它在技術領域有多相關？
但是，當問題的「域」是技術性的時候呢？
例如，情況A）採取網絡啓動。想象一下，他們正在努力完成一些相當複雜的事情（比如說Facebook的克隆），但幾乎所有的員工都是技術人員（或者至少有很強的技術理解力）。
什麼情況B）類似的情況，但有一個略少雄心勃勃的項目，和孤獨的開發人員試圖與典雅的建築創造的財產以後。
我真的很想聽聽有什麼人說。我真正想要得到的東西是DDD的好處在哪裏，缺點可能是什麼，以及在哪一點上超過另一個......
DDD實際上只是一個詳細說明設計模式福勒呼籲域名模型在Patterns of Enterprise Application Architecture。在那本書中，他將領域模型與其他組織代碼的方式進行了比較，如交易腳本，但很明顯他比其他最簡單的應用程序更適合其他所有選擇。我也做。
DDD只是極大地擴展域模型的原始概念，並提供有關我們應該如何分析並在某種程度上，這將是爲開發者對自己有利我們的域模型萬噸指導。
如果域在的問題是複雜的，則域模型（因此DDD）是很好的選擇。域名是以業務爲導向還是技術性質並不重要。 Eric Evans在他的書Domain-Driven Design中首先描述了DDD技術如何幫助他對印刷電路板應用進行建模。那肯定是一個技術領域，如果有的話！
在我目前的工作，我們正在使用DDD到基於聲明的身份涉及一種應用模式 - 另一個非常技術性的域名。
DDD是真的只是與複雜sofware處理，這也是埃文斯的書的副標題：‘搶斷複雜的軟件的核心’
埃文斯建議使用時，領域驅動設計：
Domain Complexity > Technical Complexity
我對你並沒有很好的答案，但我可以從我的角度來說，作爲一個外界人士對DDD感興趣的DDD我已經看到技術領域的概念/驅動程序蔓延到DDD對話中作爲一流的概念。一個很好的例子就是有些人提倡技術/基礎設施有限的背景。我能想到的最好的例子是Greg Young's architecture，他認爲讀取了有界的上下文，而事務寫入了另一個有界的上下文。總的來說，我認爲像這樣的東西是「域名構造」（我的名詞......如果我必須殘害真正的DDD術語，請原諒我）。它類似於OO世界中的對象，它們並不模擬現實世界中的某些東西，而是完全沖洗掉對象。
感謝您的有益迴應馬克 - 我沒有讀過福勒書，所以我會看看。我讀過埃文斯的一些DDD書籍，包括PCB分析示例。只是爲了澄清我對'技術領域'的含義 - 我只是在談論領域語言已經非常類似於軟件開發人員已經使用的語言 - 而不是其他技術領域，這些領域完全不同的語言（例如PCB設計）。 – UpTheCreek 2009-08-14 08:29:23
@Sosh：謝謝你的澄清。 Evans建議使用現有的泛在語言（Ubiquitous Language），如果該領域已經存在一個有用的語言，那麼如果您正在構建一個已經具備現成模型的應用程序，但所有方法都與此相符。這仍然不妨礙您利用DDD中可以找到的一些出色指導，例如如何處理總根，意圖展示接口，有界上下文以及什麼不是。 – 2009-08-14 08:53:49
的確很好的答案。我也喜歡這兩本書，它們對我很有用。 – KLE 2009-08-14 12:45:56