我參與了關於領域模型的知名度的有趣辯論&想知道這裏的人是否有任何良好的指導。關於領域模型及其知名度的問題
希望看到一些意見&想到這一點。
感謝所有的幫助！
不，這不是MDA的意思。它是關於將自己與特定平臺隔離，使用更高級別的表示法（UML及其操作語言）來指定系統的行爲。
是否應該公開您的域模型取決於應用程序。對於經常使用應用程序的用戶（想想你的IDE），那麼領域模型顯然是暴露的，你直接操縱該領域的對象。但對於偶爾使用的應用程序（考慮在機場的自助終端辦理登機手續），應用程序應引導用戶完成工作流程。
即使您打算屏蔽域對象，DTO也不一定必要;它取決於域對象是否與呈現UI的層位於同一個進程空間中。需要DTO的體系結構不能很好地適應新的需求，因爲它們違反了DRY原則。
事實上，可以僅從直接暴露的域對象中構建企業應用程序;這是Naked Objects模式的目標。有幾個實現這個的開源框架，包括原始的Naked Objects Framework（在Java上）。還有一個.NET的商業等價物。
關於領域對象的更多討論，我建議您查看Evans的書籍Domain-Driven Design。雅虎還有一個活躍的新聞組。
丹
全面披露：我的提交到NOF爲Java，不直接參與的.NET版本。
我同意丹。解決這個問題的一個方法是使用接口。你讓你的公共方法返回你的域對象最初實現的接口。當您發現從您的應用程序返回您的域對象不再有效時，您可以引入您的DTO並實施相關界面。雖然您的圖書館內部現在已經改變了任何消費應用程序將保持不受影響。
我對這方面的知識不太瞭解，但最近我讀到了這個blog post by Gojko Adzic，我認爲這是相關的，關於DTO如何不一定是個好主意，而且可以在不同層次上重複您的域模型以免違反DRY。