15種你應該使用模型驅動開發MDD的理由

1. MDD is faster MDD很快（真正快速開發）
在MDD應用模型中能夠指定一個比傳統的程式語言更高的抽象層次。該模型能夠自動轉化為可立即執行工作的應用程式（透過UML工具），生成可解釋/執行模型程式碼。模型中的每個元素代表了多行程式碼，這樣使得模型在一個更高的抽象層次比相應的程式碼要精簡得多，更能大道至簡。

2.MDD is more cost-effective MDD更具有成本優勢
因為MDD快速開發所以比較快地推向市場，MDD意味更少的人員 專家，更高的質量，成本只是你學習MDD的成本以及工具採購，使用MDD擴充和維護應用程式的做法也更符合成本效益。透過更高階別模型閱讀，比較容易理解應用程式。

3. MDD leads to increased quality MDD引導質量提高
因為軟體架構是在一個更高模型級別定義，然後透過引擎或框架轉換成程式碼，這樣我們能夠讓我們最優秀的人員從事引擎和框架的開發，進而提高平臺的質量。 我們在專案中學習到的最佳實踐模式可以被導引到引擎或框架程式碼產生器中，這樣將被重用到所有使用MDD的專案中。

4. MDD is less error-proneMDD很少出錯
測試會浪費很多時間，因為MDD可以確保程式碼的質量，這樣讓你可以專注於測試應用程式的特點功能即驗收測試上，不必關注通用的一些測試專案，如基礎設施相關的技術問題或安全漏洞。

5. MDD leads to meaningful validationMDD引導有意義的校驗
業務驗證都已經在更高階別的模型中完成，程式設計工具只能幫助你驗證程式碼語言的錯誤，不能驗證業務上的錯誤。

使用DSL能夠在設計時候就執行一下，這樣，錯誤資訊也是 domain-specific級別的，可見Static Verification: An External DSL Advantage一文。

6. MDD results in software being less sensitive for changes in personnelMDD可以不在乎人事變動
不需要特別的技術高手或架構師就能夠建立軟體，節約人力成本。此外，如果有人加入一個專案，比較容易理解高層次的軟體應用模型，這比試圖透過閱讀理解原始碼要輕鬆多(banq個人體會：本人曾經只用兩三個月就理解了一箇中型NGOSS級別的BOSS系統(透過together逆向工程模型化)，當然也主要因為原系統基於Hibernate的模型物件化，如果是純粹基於SQL就沒有這麼幸運了)。

7.MDD empowers domain expertsMDD授權領域專家
業務領域專家能夠注重建模，而技術專家可以專注於建立一個MDD需要的框架或DSL等工具。一個軟體系統不再只是程式編制就可以了，領域專家可以透過符號（如文字，圖形，表格）等直接表達他們對業務領域的深入理解 。

8. MDD let advanced programmers focus on the hard stuff MDD能夠讓高階程式設計師專攻難關
在MDD中，高階程式設計師的重複性工作要少得多，他們可以專注於他們工作的創造性方面。他們可以集中精力建設MDD的工具。他們還可以指導初級開發或領域的專家，也可以申請領取困難攻關，領域專家可以專注例如模型的圖形使用者介面，流程和業務規則。而應用程式的整合部分（使用webservices，API呼叫，資料庫整合等）對於領域專家來說，存在太大困難，可以由高階程式設計師來完成。

9. MDD bridges the gap between business and IT MDD在業務和IT之間架設了橋樑
領域專家（或系統分析師）可以直接參與業務發展程式（見第7點）。
技術專家（軟體應用）可以在一個更高的層次定義儘可能和領域概念的定義宣告有關模型。
透過在模型和模型實現之間定義一個重要的轉換機制，就可以在業務和IT技術之間建立一個橋樑，比如使用一個基於model-driven SOA的框架。

10. MDD results in software being less sensitive for changes in business requirements MDD可以減少業務需求帶來改變的影響面
對軟體開發的問題之一是業務需求經常變化速度超過了軟體系統支援改變，這對於企業是一個重點戰略問題：能夠保持足夠長的時間調整其核心業務與IT流程。
MDD使軟體開發更快（見第1點），它也導致更容易改變應用（因為第2點和6）。如果在業務需求和軟體之間的存在一個聯絡，那麼應用程式甚至有可能自動適應部分模型的變化（見第9點）

11. MDD results in software being less sensitive for changes in technology MDD導致技術對變化不是太敏感
技術變化很快， Java EE, SOA / SOBA, webservices, REST, SCA, OSGi等等，甚至遷移到雲端計算環境，當您希望您的應用程式遷移到其他技術時，MDD可以確保你不必改變你的應用模型，。唯一需要改變的程式碼生成器（或DSL直譯器）。改變後的程式碼生成器（或新增額外的程式碼生成選項）可以幫助所有的應用程式模型直接轉換成基於新技術架構的程式碼。

12. MDD really enforces architecture MDD增強架構
當使用MDD開發軟體應用程式，保證符合選定架構。你可以真正實現架構標準化， 構建架構原則Constructional architecture principles能夠知道設計構建，並且能夠反映在程式碼生成器或直譯器中。

13. MDD captures domain knowledge MDD可以截獲領域知識
關於MDD的優點是，你不是隻建立軟體，但你也捕捉正式高層次的領域知識模型。在大多數情況下這方面的知識是不明確，見文章基於DDD的DSL

14. MDD provides up-to-date documentation MDD提供最新的文件
當使用MDD是，您不會遭遇不完整或過時的檔案，因為該模型使用正確的抽象，可以讓領域專家和客戶都能看懂。

15. MDD enables to focus on business problems instead of technology MDD能夠關注業務而不是技術
停止討論使用WS-* 或者 REST，MDD能夠讓你專注於業務問題如何解決，而不是著眼於如何解決這些問題的技術支撐。