域驅動設計的缺點？

我可能對DDD有一個愚蠢的問題： DDD是否有任何缺點？我的意思是，除了在沒有必要或需要時使用它。（如小/不復雜projets）域驅動設計的缺點？

感謝

2011-03-02 Peter

小項目，應用DDD不值得。 @DOK所以主要缺點是成本高。 – Peter 2011-03-02 13:59:43

我會看到高成本作爲缺點，它不會給你帶來某種好處。以高質量應用程序形式出現的優異結果可能證明成本較高。正如我所看到的那樣，不僅在開發過程中，而且在應用程序的整個生命週期中都會出現更高的成本，因爲它需要維護應用程序的每個人都理解設計。 – DOK 2011-03-04 14:22:30

我發現DDD有時會導致更多的工作。我也不相信這個概念。我的意思是，在我看來，域名專家和編碼人員之間不需要保持一致。我的xp是，如果我和客戶談話並分析他們的需求，我的應用程序就不僅僅足夠清晰，而且足夠用戶友好且易於掌握和使用，與我在DDD中編寫代碼時相同。 DDD確實有一些有趣的概念，這讓我重新思考我一直在以某種方式做的事情，但我認爲三層模式與某些DDD概念相結合可以減少工作量。 – Lawrence 2014-06-16 21:34:05

我發現DDD的討論在Microsoft Application Architecture Guide將有助於理解特定風格的挑戰：

由於軟件的核心域模型，這是該共享語言的直接投影，它允許團隊通過分析圍繞它的語言在軟件中快速找到差距。創建公共語言不僅僅是一個練習，接受來自的領域專家的信息並應用它。很多時候，通信問題 開發團隊內到期不僅誤會語域的，而且由於事實域的語言本身模棱兩可。領域驅動設計過程不僅保留了實現語言所用的的目標，而且還改進和完善了域的語言。這在輪好利軟件被建成，因爲該模型是直接投影的領域語言。

爲了幫助維持模型一個純粹的和有用的語言結構，通常必須實現域模型內的巨大交易隔離和封裝的。因此，基於域驅動設計的系統可能會以較高的成本來到。儘管領域驅動設計提供許多技術優勢，如可維護性，應當適用只有複雜的領域，其中模型和語言過程在複雜的信息，並在該通信提供清晰的好處制定一個通用的瞭解域。

來源

2011-03-02 13:05:11 DOK

Martin Fowler的他在「POEA」一書中有時間和內容domain logic patterns使用的大討論。

例如，最簡單的模式Transaction Script不涉及域模型。

來源

2011-03-04 09:16:17

這很容易做錯。

來源

2011-03-04 09:29:14 smartcaveman

Eric Evans在JavaOne的演講中表示，DDD最適用於存在業務域複雜性的批號。此外，他明確指出，DDD不適用於存在大量技術複雜性但具有小業務域複雜性的問題。後者的一個例子是一個嵌入式系統，它具有非常簡單的輸入（可能與其擁有的狀態數量無關），同時呈現出大量的技術複雜性（在使硬件正常工作方面）。

我們該如何去關於量化很多或有點，這是一個開放的主題。但敘述應作爲DDD何時何地最適用的指南。

- 編輯 -

我通過電驢得到了視頻演示，我從來沒有能夠找到在YouTube或類似的視頻場館同樣的講座。

來源

2011-08-22 21:41:01

在意大利會議上，我談到了這個話題（請參閱these slides）。

DDD項目需要聘請常常昂貴的領域專家，因爲他們持有寶貴的知識（如果您不需要領域專家，則不需要DDD）。
此外DDD需要建模方的強大技能。特別是他們必須是：

謙虛，因爲他們不得不接受他們的無知和專家
真的精通OOP
勤奮學習，因爲他們要跟蹤決策
Comunicative，因爲他們有解釋域到其他開發者（甚至通過文檔）

找到這樣開發人員可以比預期的要貴得多，因爲你可以真正知道他們所擅長的日經過幾個月的試驗之後，這份工作是否成功

來源

2013-03-11 23:08:17

域驅動設計的缺點？

回答

相關問題