2008-11-04 85 views
3

模型驅動的軟件開發。模型驅動開發的工具(最佳實踐?)?

據我所知,它提高了設計的抽象層次,以更好地反映軟件將嘗試運行的領域。這只是一句話。

領域專家(客戶)與開發人員之間的溝通對於使此方法有效至關重要。我想知道的是,如果有一套工具套件或一組最佳實踐將有助於MDSD的最初推力?一旦該域充實了,那麼將該模型映射到ORM(或其他)呢?

我只是潛入MDSD和DSL的領域,所以任何建設性的想法或意見將appriciated。

回答

2

如果您正在Microsoft平臺上開發,您可能還想查看奧斯陸。有一個很好的概述這裏: http://www.pluralsight.com/community/blogs/aaron/archive/2008/11/03/introducing-quot-oslo-quot.aspx

這裏有一噸的從克里斯銷售鏈接: http://www.sellsbrothers.com/news/showTopic.aspx?ixTopic=2197

我不準備等同於模型驅動的開發領域驅動設計,只是還沒有。

您可能也想看看模型驅動架構(OMG MDA)的透視圖,雖然可能沒有太多的自己滾動。

模型驅動中的一個大問題 - 任何事情都與專業知識來自哪裏,從模型派生實現以及什麼級別的維護(和調試)發生在什麼地方。我對可用書籍的測試將是他們如何使管道可以理解,以及如何理解從建模到部署再回來的路徑。

+0

正是! MDSD和DDD是不同的!他們經常被集中在一起。 高層次他們有類似的目標,但達到這些目標的手段有着完全不同的優先級! – jbandi 2008-11-26 11:08:50

2

如果您在.net中編程,您應該閱讀Jimmy Nielsson的「應用領域驅動設計和模式」。他還有一個關於ORM(NHibernate),SOA和依賴注入的部分。

無論如何,您應該看看Eric Evans的「Domain Driven Design」。這是一個經典的地方,你可以找到有關域驅動設計的模式和最佳實踐的寶貴信息。

1

聲明:我是商業應用程序的開發人員。我在企業IT戰略的經驗中肯定了以下觀點。我知道,還有其他軟件開發領域。特別是在工業和/或嵌入式系統開發中,世界可能看起來不同。

我認爲MDSD仍然與代碼生成密切相關。

只有當代碼包含大量噪音和/或非常重複時,代碼生成纔有用。換句話說,當你的代碼不能主要關注基本的複雜性時,而是被意外的複雜性所污染。

在我看來,當前平臺和框架的趨勢正是消除了意外的複雜性,並讓應用程序代碼專注於基本的複雜性。

因此,這些新的平臺/框架爲MDSD運動帶來了很大的風險。

DSLs(文本的)是另一種趨勢,試圖使唯一的關注重點複雜性。雖然DSL可以用作代碼生成源,但它們並不主要與代碼生成相關聯。 DSL(特別是內部DSL)基本上允許它在運行時被解釋/執行。 [運行時代碼生成在兩者之間]。

因此,即使DSL經常與MDSD一起提到,我認爲它們確實是MDSD的替代品。鑑於目前的炒作,他們也從MDSD運動中汲取了動力。

如果你已經達到了最終消除你的代碼中的意外複雜性的目標(我知道這是虛構的),那麼你已經到達了你的業務問題的文本模型。這不能再簡化!

好框和圖表不提供抽象層次的另一個簡化或提升!它們可能對可視化有好處,但即使這樣也是有問題的。畫面並不總是掌握複雜性的最佳表現形式!此外,MDSD中涉及的工具的當前狀態還增加了另一個級別的意外複雜性(思考:同步,差異/合併,重構......),這基本上無效了簡化的最終目標!

請看下面的ActiveRecord模型,我的理論的說明:

class Firm < ActiveRecord::Base 
    has_many :clients 
    has_one :account 
    belongs_to :conglomorate 
end 

我不認爲這可以是任何更加簡化。任何帶有方框和線條的圖形表示都不會簡化,並且不會提供更多便利(考慮佈局,重構,搜索,區分...)。

+0

雖然我喜歡你的回答,但我會指出那些消除意外複雜性的框架,就像你說的那樣,仍然不會抽象出實現細節。 RoR中的模型對象僅在該框架的上下文中有用。你不能從單獨的派生.NET,Java或C++實現 – 2008-11-26 11:26:33

1

MDD可能非常複雜或相對簡單。

如果您想從各種模型(例如UML)自動轉換爲代碼並執行往返工程等等,您可以獲得一些漂亮的花哨工具。

或者

您可以繪製模型和構建代碼更多或更少的手,用單向(型號代碼)改造。

首先構建模型的想法是一個行之有效的最佳實踐。它通常被稱爲「設計」。當人們將設計與規範混淆時,就會出現問題。將構建的模型不是編程規範。這是一個抽象,可用於評估正確性,定義測試用例,編寫規範等。

您不必模擬所有內容。您可以通過創建數據模型來啓動MDD,而不依賴於任何特定的實現。

  1. 您使用UML繪製模型。

  2. 您將UML轉換爲類定義。

  3. 您使用ORM層(或ODBMS)將模型映射到某種存儲。

你不需要比這更多。你需要做的是在你解決太多其他問題之前,把注意力放在模型上。

這個問題通常來自軟件開發過程中發生的各種過早優化。早日進入RDBMS物理設計。早期進入網頁設計並使用它來驅動數據模型。早期進入定義服務器體系結構和分配存儲空間。