模型驅動開發(fā)的誤解和挑戰(zhàn)
多年以來，采用模型驅動開發(fā)（MDD）的水平似乎仍沒預期的那么好。阻礙、限制MDD使用的因素有很多，例如對實際的MDD成功案例缺乏認知、不確定如何在平常使用MDD、缺少預先投資的撥款模式、或是沒有戰(zhàn)略舉措的重點。
如果你過去嘗試過MDD，那你很可能遇到了一些挫折，導致你現(xiàn)在不再用它。也或許你正在嘗試采用MDD，而又面臨著一些挑戰(zhàn)和阻礙。無論你遇到上述哪種情況，本文都對你有所幫助。我們會在本文中看一看與采用MDD相關的挑戰(zhàn)和誤解。
建模早已證明了它在改善溝通、促進業(yè)務編排、提升質量、提高生產率上的價值。它的使用范圍很廣，分析、設計和開發(fā)都會有所涉及?？紤]到這一點，我們就來看看有關MDD的諸多誤解和挑戰(zhàn)，我們又該怎樣利用現(xiàn)代方法和相關工具集解決這些問題。
1-挑戰(zhàn)：方法不當且不可用
過去，MDD的一個關鍵抑制因素是人們實施活動的時候沒有現(xiàn)成的MDD最佳實踐。比如說，人們在閱讀有關如何執(zhí)行特定任務（諸如設計高可用的解決方案）的過程文檔時，文檔里并沒有任何MDD的內容。為了得到MDD實踐，人們不得不到論文或書本里去找，然后再應用到現(xiàn)有的非MDD文檔上。
如今，MDD從業(yè)者在進行日常工作時，可用的MDD指南已經(jīng)越來越多，而且那些信息嵌在他們每天使用的工具中。我們先看看開發(fā)過程，它包括利用MDD原則的“工具向導”最佳實踐，這些“工具向導”隸屬于整個方法和過程。
特定任務的指南（例如需求評審、設計用戶接口或設計高可用的解決方案）現(xiàn)在都包含指向MDD內容的鏈接。比如推薦設計模式、提供設計中應用模式的指南、利用現(xiàn)成工具中的模式實現(xiàn)。
以前還有另一個阻礙因素，就是MDD與特定開發(fā)方法過度摻雜，人們無法提取MDD最佳實踐，并將其應用到不同的場景中。一個典型的例子就是面向對象分析和設計（OOAD）中存在大量工具，你要么采用全部的OOAD內容，將其作為從MDD受益的一部分內容，要么就完全拋棄OOAD。MDD的最佳實踐曾是OOAD框架的一部分，但人們并不知道如何在框架之外利用這些最佳實踐。抽取出MDD的內容并將其應用到不同的場景中是不可能的。
這些因素再加上其他一些原因導致企業(yè)很難在它們的環(huán)境里采用最佳實踐（包括MDD最佳實踐）。公司已經(jīng)有了合適的過程和方法，而給這些方法添加MDD方面的內容卻很困難。
為了在組織和特定類型的項目中采用MDD，業(yè)界在裁剪特定開發(fā)過程方面已經(jīng)做得越來越好。比如有的研討會旨在指導團隊完成定制的開發(fā)過程，這通常被稱作“方法采用研討會”。研討會的目的是針對特定項目裁剪現(xiàn)有的方法內容，它通常會涉及以下人員：過程工程師（管理組織開發(fā)過程的人）、首席架構師、開發(fā)人員組長和項目經(jīng)理。
支持定制后，方法工具浮出水面，比如Rational Method Composer和Eclipse Process Framework Composer，它們包含定制的最佳實踐庫。這些工具的思想是整理、打包最佳實踐，用工具為組織裁剪并采用這些最佳實踐。在工具中，你選擇想要采用的某些方法元素，對它們進行修改、編輯，并將其組織成希望關注的過程。然后將該過程以可讀格式（例如HTML）在組織內發(fā)布，供從業(yè)者在日常工作中遵循。
盡管使用上述工具和方法的可用指南有很多，但仍然要求用戶找到、理解并遵照指南?？缭竭@一障礙的措施是，除了在工具里提供指南之外，還要將方案的全面自動化。舉例來說，你能在使用基于Eclipse的產品時利用備忘單（Cheat Sheets）。備忘單提供完成任務的步驟指南，并能自動化工作流里的步驟。
下一節(jié)我們會討論關于模式實現(xiàn)的機制。不管選用什么方法，要點都是獲取越來越多的指南，并將其落實到工具中，從而更好地指導用戶充分利用模型。
正如軟件解決方案可能會過度工程化一樣，創(chuàng)建指南也會發(fā)生同樣的問題。克服這個挑戰(zhàn)的最后一點是要務實、主動。計算出構建方案所需步驟的全部細節(jié)，無論從價值來說還是從時間來說都沒有什么意義。那關鍵的步驟是什么呢？他們如何與團隊的技術相結合？在文檔化步驟上投入時間的意義何在？相對于自動化，在創(chuàng)建靜態(tài)文檔上又該投入多少呢？
過程，尤其是MDD，都不是放之四海而皆準的，這將在“4-誤解”中討論。
2-挑戰(zhàn)：基礎設施和工具不能從MDD獲益
近幾年，我們看到建模工具已不局限于對特定圖形符號（比如UML）的支持了，經(jīng)過發(fā)展，它已然能幫助從業(yè)者完成工作。這些工具不僅支持圖形建模符號，也內置了MDD特性，這些特性有利于：
◆業(yè)務編排：業(yè)務編排是SOA等成功方法的關鍵方面。通過使用MDD模型、自動化、以及與之關聯(lián)的“追蹤”，你能記錄決策的原因，跟蹤滿足業(yè)務需求的所有方式。另外，我們可以研究利用MDD的特定版本，比如業(yè)務驅動開發(fā)（BDD）。顧名思義，BDD關注的是業(yè)務建模。你可以在這種情況下進行建模，也可以在某些情況下模擬組成業(yè)務的流程。
◆高質量：由于實踐內建在工具中，并進行了自動化處理，因此出錯的幾率非常小，甚至不會出錯。
◆增強的一致性和治理：由于工具支持指南和最佳實踐的自動化，所以提高了解決方案中元素的一致性。另外，工具也能確保構建的元素是固定的，并與需求和最佳實踐保持一致。
◆提高的生產率：重復、耗時的工作現(xiàn)在都自動化了。從業(yè)者可以“復用”，把時間花在最緊要的事情上（比如業(yè)務邏輯）。依賴自動構建，用戶群的復雜度和自動化要么可以在當前項目中實現(xiàn)，要么可以分散在多個項目中實現(xiàn)。
◆改善的溝通：使用模型、工具和自動化，從業(yè)者（例如架構師）能針對不同的受眾創(chuàng)建不同的視圖。
◆影響分析：MDD的可追蹤性能讓你分析出需求變更對解決方案造成的影響，反之亦然。
讓我們以設計模式為例，來說明工具如何給MDD帶來了活力。假設某本書中描述了設計模式，我們將其稱為模式規(guī)范。該規(guī)范非常有用。它描述了模式的使用時機、模式的特征，以及使用模式的好處和意義。模式規(guī)范能幫助人們理解模式并做出恰當?shù)倪x擇。但模式規(guī)范并不能確保設計的高質量和生產率的提高。為了從中受益，你必須將這些模式“自動化”。我們將其稱為模式實現(xiàn)，也就是模式規(guī)范在工具中的可復用編輯。使用模式實現(xiàn)，設計者可以將模式快速應用到他們的設計中，也能確保這些應用準確無誤。
領域獨立的工具不太可能內置領域所需的所有MDD工件。工具除了提供開箱即用的MDD工件外（比如一組設計模式實現(xiàn)），也允許你擴展現(xiàn)有的工件、創(chuàng)建自己的工件?，F(xiàn)在的工具包含“擴展框架”，以及最佳實踐、模板和API。Rational Software Architect之類的工具還允許你構建適用于領域的MDD工件（例如模式實現(xiàn)、規(guī)則、約束等）。
既然你能構建這些MDD工件，那么基于資產的開發(fā)（ABD）就能讓你與他人共享工件、提升復用的實踐和基礎設施。換句話說，ABD最佳實踐和基礎設施的改進支撐了MDD的采用進程。諸如Rational Asset Manager的可復用資產庫能讓你管理可復用的軟件工件，讓開發(fā)社區(qū)共享和復用工件。試想一個為領域創(chuàng)建的模式實現(xiàn)，你現(xiàn)在可以把它提交到資產庫中，該模式經(jīng)過評審和認可，社區(qū)中的其他從業(yè)者就可以復用它了。作為這個生態(tài)系統(tǒng)的一部分，你可以監(jiān)控資產被復用的時機和方式，收集反饋信息并確保整個團隊在使用合適資產的正確版本。
我們重新回到務實和實用上來。在對用戶和用戶所在組織有意義的情況下，ABD及復用倡議才需要被采用。你需要識別出你的成熟度級別，并采用支持該級別的工具和過程。通過事先思考和計劃，你可以隨需確定、推廣ABD計劃，避免不必要的開銷和成本。
3-誤解：MDD==UML？
有一個誤解是MDD意味著你必須使用統(tǒng)一建模語言（UML）——現(xiàn)狀如此，完全是因為來自對象管理組織（OMG）的UML規(guī)范進行了這樣的描述。消除這一誤解的方法有很多。
打消這種念頭的第一種方法是用MDD的方法工作，這只需要你在執(zhí)行任務時把模型作為關鍵的工件使用，并使用利用這些模型的自動化機制。在這種情況下，模型是用語言簡化了的現(xiàn)實，而這些語言具有定義良好的語法和語義。因此，可以在MDD中使用的語言有很多，而不僅僅是UML。
在大多數(shù)情況下，我們確實要為手頭上的任務選擇合適的工具。如果我們的MDD需要標準化、為人熟知、被廣泛支持的語言，那UML就是一個不錯的選擇。UML也是可擴展的。嚴格來說，它能通過配置（提供定制的元素、屬性和約束）進行定制。這能讓UML對所作的工作來說變得具體，也能讓語言更加易學易用。增強建模語言可用性或針對性的另一種方式是創(chuàng)建你自己的領域特定語言（DSL）。
要記住的是，我們受益于使用的語言和創(chuàng)建的模型。為了指導投資，我們要權衡以下問題：
◆是否能有效地設計和理解解空間？
◆能否輕松地和其他人溝通？
◆是否能基于已經(jīng)創(chuàng)建好的模型生成方案的其他部分？
◆能否有效利用開發(fā)生命期之外的結果？
◆是否能從實現(xiàn)追溯到設計？甚至需求？
4-誤解：MDD放之四海而皆準
根據(jù)前面的誤解可以看出，MDD顯然不是放之四海而皆準的解決方法，任何非預設的生產線工具集都可以用來構建產品。MDD就是用模型為特定情況增加價值，它適用于特定領域，跟你所開發(fā)的軟件類型也是配套的。因此，我們能在自己的場景中看到很多使用MDD、有意義的方式。
其中一個例子是，我們可以和傳統(tǒng)的面向對象分析和設計（OOAD）一起使用MDD。在審視OOAD和MDD的時候，往往會發(fā)現(xiàn)使用了很多模型，比如用例、分析、設計和實現(xiàn)。有很多現(xiàn)成的例子和文檔演示了如何使用這些模型來完成方案。但這并不意味著你必須用上所有的模型。關鍵是我們要有效地利用抽象。抽象的層次取決于所處的場景、使用的語言、相關的約束、規(guī)則和假設，以及可能實施的自動化。
除了在模型數(shù)量（和相關的抽象層次）上務實之外，也要切合實際地選擇模型中用于交流的圖表。比如說，如果使用UML作為建模語言，就沒必要使用所有可用的圖表類型（類圖、交互圖……）。語言中有一系列圖表可供選擇，一般用途的建模語言能為各種需求提供服務就可以了。在特定情形下，對于你試圖完成的工作來說，只選擇那些能為其增加價值、有助于溝通的圖表才是有意義的。至于完整性，我們可以進行進一步的討論，要注意的是，即使在一個圖表中，你也不必使用所有可用的模型元素。
5-誤解：圖表就是模型
MDD中關鍵的一點是要認識到我們在創(chuàng)建模型——正如前面所討論的，模型是用語言簡化現(xiàn)實，該語言要具有良好定義的語法和語義。我們在模型中可以發(fā)現(xiàn)大量模型元素和一組圖表。每種圖表都提供了模型元素之上的一個視圖。每個模型元素屬于零或多個圖表。我們要關注模型元素——它們是什么？有哪些關系？有什么屬性？我們通常使用圖表來幫助我們理清這些問題。此外，我們還將圖表作為和其他人溝通的方式。但模型的關鍵信息存在于模型元素中——因為這能讓我們生成所需的視圖、創(chuàng)建所需的圖表，從模型生成其他元素。如果MDD只是圖表，那工具能畫出漂亮的圖片就能滿足我們的需求了。這并不是說圖表（和支持圖表的工具）不重要。創(chuàng)建模型和圖表的工具需要進行調整，以適合目標受眾。#p#
結合有選擇性地使用圖表，我們還能利用視角讓模型更加可用、更加利于溝通。視角是組織模型的一種方式，以便模型的某些方面可以提供額外的圖表，使模型面向各種各樣的受眾。透視圖通常只包含圖表，而沒有額外的語義元素。嚴格來說，在你更新語義元素時，透視圖會自動保持同步。使用透視圖可以讓你與其他角色和小組有效溝通，從而為MDD增加價值。每個小組都想理解方案中的一部分內容，也就是與他們的需求相關的那部分。在不打亂模型、不構建獨立模型、或是不在維護同一元素的多個版本上浪費時間的情況下，透視圖可以支持這些需求。請記住，我的意思并不是讓你支持所有不同的小組，并創(chuàng)建龐大的一組透視圖。再次強調一下，關鍵是要務實，要創(chuàng)建有意義、能帶來價值的圖表與視角。
6-誤解：代碼就是模型，模型就是代碼
以前對MDD的誤解之一就是它只能應用于代碼。MDD基本上被局限在一個較低的抽象層次，因此它的影響也很有限。很多人只用MDD工具“可視化”代碼（也就是將代碼圖形化的逆向轉換）。這樣是有好處的，比如說，更好地理解大段代碼，以及組件或類之間的關系。但撇開這些來說，代碼可視化并不能獲得先前討論的那些MDD優(yōu)勢（比如業(yè)務編排、改善質量、提高生產率或影響分析），因為它所作的一切也就是讓你以圖形化的方式查看代碼而已。這是基本、初級的圖形使用方法，和預期的一樣，它的投資低，收益也低。
再復雜一點兒，在代碼可視化之后，讓可視化結果和預期的設計保持一致。例如設計師或架構師想評審開發(fā)團隊開發(fā)的代碼，代碼的可視化視圖就能讓他們對代碼和設計進行比較，因為可視化結果和設計使用了相同的可視化技術（比如UML類）。不過，盡管可視化結果和設計用相同的語言表示，但兩者之間仍然有很大差距，因為它們所處的抽象層次不同。MDD工具憑借可視化、可追蹤性、分析和發(fā)現(xiàn)功能、重構支持能幫助設計師完成工作。一旦標注出設計和代碼之間有分歧的地方，人工干預就必不可少了，設計師就要和開發(fā)團隊進行溝通。這能提升價值，但仍然無法完全擁有MDD的優(yōu)勢。為了支持分析和溝通，需要增加時間和精力，而且每個項目都需要投入多次。
MDD應該適用于任何層次的抽象，并有助于不同層次之間的連通。你應該在較高層次的抽象上進行建模。以分析模型為例（像系統(tǒng)的用例模型），它是設計模型的輸入。分析模型中的有些元素可以在設計中予以利用。比如說，功能域信息分類（包）和用例可以用來創(chuàng)建設計模型中交互圖的基礎模板，用例會在設計模型中實現(xiàn)。利用工具及其擴展性，你可以修改“分析到設計”的轉換過程，接著讓組織內的成員在質量和生產率上獲益。
MDD適用于所有層次的抽象，而抽象的層次是無窮盡的。要為領域和組織選擇有意義的抽象層次。例如，在SOA中，可以在開發(fā)方案時采用以下的抽象層次：
◆業(yè)務：該層次對業(yè)務策劃師、業(yè)務分析師或產品所有者來說是有意義的。在這個層次上，模型元素是業(yè)務目標、關鍵性能指標、業(yè)務方針和功能域之類的內容。
◆分析：分析和設計通常要一起看，分析模型的元素有時會演進為設計元素。在SOA里，考慮分析是很重要的，因為分析是支持業(yè)務元素的技術模型元素的起點。
◆設計：SOA方案中，大多數(shù)在架構上重要的元素都是在這個層次建模的。設計時要用文檔記錄架構的關鍵元素，以及它們的實現(xiàn)方法。
◆實現(xiàn)：實現(xiàn)是“代碼”層次的抽象。在該層中，你可以用MDD基于設計生成代碼存根，并在需要的時候讓代碼和設計保持一致。
另一方面會出現(xiàn)這樣的情況：人們熱衷于模型和MDD，甚至僅僅為了建模而建模，卻忘了把模型轉換成可操作或可執(zhí)行的內容。架構師可以和利益相關者、設計者和開發(fā)人員溝通，但你仍然不能完全受益于MDD。在你策劃MDD的策略和方法時，要思考一下如何利用模型。譬如，部署方案最終用什么平臺？如何提高代碼質量和開發(fā)人員的生產率？是否能將模型轉換成代碼存根？
另外，模型所包含的有用設計信息要多于生成代碼所需的信息，所以我們還要看看其它方式，來利用這些已捕獲的重要而有價值的信息。這包括文檔的生成、測試用例、部署腳本等，這樣就能顯著提高項目的整體生產率。眾所周知，實際的代碼編寫只是整個項目的一部分工作而已。
沒有什么銀彈。所需的代碼并非都能自動生成（除非你的領域非常小）。最后，你必須處理模型和代碼，MDD則會指導你利用模型、保持代碼與模型之間的同步。
不過雙向工程怎么樣呢？如何利用自動化保持不同抽象層次之間的模型同步呢？這也是一般方案中較為棘手的問題。例如，從較高層次的模型向較低層次的模型轉換時，許多元素會展開——一個元素會在較低層次上演化出多個元素。一旦創(chuàng)建了較高層次的模型，用戶就可以更新、移除、添加較低層次上的模型元素。那又該如何映射回較高層次的模型去呢？若干組詳細的元素又怎樣轉換/映射到少量的高層次元素呢？面臨這樣的挑戰(zhàn)，就很有必要想清楚，追求的這種方法到底是不是開發(fā)方法的一部分。
由于修改極可能在代碼級別發(fā)生，所以若沒有保持模型和代碼一致的方法，模型很快就只剩文檔了。最近，Rational Software Architect之類的工具在“保持一致”方面有了很大的改進，提供了可視化代碼、比較和合并的功能。請注意，用于協(xié)調這些變化的方法比工具化的能力更為重要，這和治理也是相關的。舉例來說，架構師看到了代碼和模型之間的差異，怎么辦呢？去和開發(fā)人員討論？讓開發(fā)人員修改代碼？還是架構師修改模型？正如你所看到的，這些都不是完全自動化的方法。
已經(jīng)取得巨大成功的另一個方式是預先在工具化上投資（要么購買要么定制），通過約束、規(guī)則和假設減小問題空間。對問題空間所能做的限制越多，生成高比例解決方案、減少抽象層次、消除雙向工程需求的可能性就越大。在這種情況下，今后的關注點只需放在工程上。
7-挑戰(zhàn)：平臺無關性面臨挑戰(zhàn)
雖然不確定平臺無關性發(fā)生的時間或原因，但是在高層次上進行建模、然后生成解決方案的想法已經(jīng)引起了廣泛關注。或許平臺無關性來自于MDA的平臺無關模型，也或許來自其它地方。不管來源如何，都要認識到很難從很高層次的內容進行延展，也很難將一種表示定位到許多不同類型的實現(xiàn)上去。已經(jīng)有一些解決方案能讓用戶利用模型生成全部的結果代碼了。但在那些情況下，也正如前面小節(jié)中所討論的，工具化對領域來說很有針對性，而且利用了一組約束、規(guī)則和假設才使轉變成為可能。解決方案空間比較狹小，這樣才為生成高層次的內容提供了可能性。隨著解決方案空間的擴展，生成會變得越來越困難。
就連遷移到DSL上也會提出這樣的問題：使用相同的模型作為輸入，生成不同的底層實現(xiàn)有多容易。在利用DSL的時候，關鍵應該是具體的領域和當前的項目。正如從許多敏捷過程中（以及自己的經(jīng)驗）學到的，過度工程化、計算每種可能性都要付出代價。這同樣適用于建模和使用的語言。針對具體領域并不一定就是什么壞事，事實上它反而是最佳利益。不過，創(chuàng)建一個領域特定的解決方案，再大范圍地加以應用是不切實際的。
8-挑戰(zhàn)：保持編碼人員的創(chuàng)造力
在我們轉向MDD，期望簡化設計表達、改善溝通、生成部分解決方案的時候，我們還需要認識到這會對團隊產生影響。有些團隊成員可能喜歡在較低的抽象層次工作；他們也許會在場景建模時覺得拘束，反而在努力實現(xiàn)解決方案的時候感到自如。這些擔心并非都是合理的，但還是要聽出“弦外之音”。我們需要保證每個團隊成員都能發(fā)揮最大的作用。
即使在處理模型的時候，我們也需要底層實現(xiàn)的相關專業(yè)知識。應該使用什么框架？這些框架如何整合？下面以模式為例進行說明。構建模式實現(xiàn)的關鍵輸入是參考解決方案，也就是樣例，它用來決定模式實現(xiàn)應該做什么以及怎么做。如果我們要構建自己的模式實現(xiàn)，那誰來構建樣例？誰來判定該樣例是不是解決問題的最佳方式？既然期望能簡化建模體驗，那又由誰來給出規(guī)則、假設和約束呢？又該怎樣把它們編輯到人人都要用的工具中呢？這些問題都強調，有很多地方都需要專業(yè)知識、創(chuàng)造性、以及解決問題的技巧。MDD策劃、啟動時有一點非常重要，那就是與團隊成員溝通這些挑戰(zhàn)，并確保每個成員都能以有建設性、有效率的方式為項目效力。反思一下過去的項目，真正創(chuàng)新的工作花費了多少時間？而機械、乏味、重復的任務又占用了多少時間？
9、挑戰(zhàn)：沒有可利用的內容
和其它相對比較新的方法一樣，在最佳實踐被充分理解和基礎設施就位之前，產出的內容都很有限。現(xiàn)在MDD在軟件行業(yè)越來越成熟，有了越來越多的推進力，可以看到，高質量的MDD內容和資產也越來越多。讓這些內容從一開始就可用，對采用MDD來說是至關重要的。
面對有挑戰(zhàn)性的業(yè)務問題，僅有工具和基礎設施還不足以交付解決這些問題的軟件。最終解決問題的往往都不是工具，而是使用工具的人[4]。如果希望大家使用工具，那么最初就有工具的話，情況就會有很大不同。你是否曾經(jīng)面對過一塊白板、一張紙或IDE工作空間？如果你一開始就有參考或模板，或者有內容指導、組織你的方法，豈不是更容易一些？
這里討論的MDD內容不僅僅是設計模式或UML項目模板。我們所說的內容是指行業(yè)或方案的參考架構（比如呼叫中心參考架構或銀行參考架構）、作為可執(zhí)行模型的行業(yè)標準集（比如保險業(yè)的ACORD或電信行業(yè)的SID）或實現(xiàn)存根的模板大全。這類資產的一個成功案例就是WebSphere Business Services Fabric（WBSF）的行業(yè)內容包（ICPs）。WBSF框架由運行時和相關工具組成。ICPs為特定行業(yè)（領域）提供了可定制的內容，從而成為框架的有益補充。這些內容包括不同抽象層次（比如業(yè)務、設計和實現(xiàn)）上的模型和模板，它們遵循行業(yè)標準，由組織加以裁剪和采用。
這些資產的核心價值在于提供了更多的業(yè)務價值，而且更接近組織的戰(zhàn)略。換句話說，業(yè)務能看到它們會影響損益底線。如果我們比較可復用設計模式的價值和行業(yè)框架的價值，毫無疑問，行業(yè)框架能創(chuàng)造更高的價值。但行業(yè)架構的適用性是很有限的。譬如說，如果是保險業(yè)的行業(yè)架構，那就無法在電信行業(yè)中使用。與此相反，設計模式的應用與行業(yè)無關，但設計模式提供的價值卻有限，而且離損益底線更遠。跟基于資產的開發(fā)（ABD）社區(qū)所認可的一樣，讓內容可定制（技術術語是“可變點”）有助于擴大其適用性。
要注意的是，此類內容并不局限在高層次的抽象上（比如業(yè)務模型）。由于運營資產都是可執(zhí)行的，所以它們會影響損益底線。例如安全領域的資產，能復用、改變的細粒度訪問控制策略?？梢源_定的是，這些會對損益底線有所影響，人們也能從這里建立到高層次業(yè)務安全策略的聯(lián)系。
10、誤解：MDD僅用于開發(fā)
構建軟件解決方案的時候，使用模型來指定架構、關聯(lián)的服務和組件具有很大的價值，從解決方案的其它方面來說也是如此。但這僅僅是MDD給組織帶來的一部分價值。要想利用模型并從中獲益，就沒必要把使用范圍限定得這么窄。
我們之前曾將業(yè)務驅動開發(fā)（BDD）作為MDD的特例進行了討論。那種情況下的焦點是業(yè)務建模——業(yè)務里的過程是什么？它們如何工作？如何對它們進行優(yōu)化？如果在這部分沒有做好，那就會遭遇“無用的信息輸入和輸出（Garbage In，Garbage Out）”。
此外，我們還能利用模型來支持規(guī)范一致性。模型能提供易于理解的表示，詳細說明結果方案如何支持規(guī)范要求。比如說，要表明組織是如何對細分客戶群、業(yè)務范圍（LOB）或渠道持續(xù)應用某規(guī)則的，就能用模型來實現(xiàn)這一規(guī)范需求。只提供代碼到文檔的一致性并不足以成為一個最佳的方案。
如果要增強已有解決方案的功能，又怎么樣呢？如果需求‘A’變化了，這對系統(tǒng)又會有什么影響呢？你如何確定IT布局中的哪些部分應該進行驗證和修改呢？如果不能跟蹤從需求到實現(xiàn)的過程，這個問題就很難回答，回答的代價也很高。
在企業(yè)里利用MDD的例子還包括對企業(yè)架構和運作建模的支持，但也不局限于此。雖然目標千差萬別，但我們仍期望能夠溝通、利用抽象、保證治理、支持一致性、提高生產率。
總結
MDD帶來了很多好處，它能促進溝通、改進業(yè)務編排、提升質量、提高生產率。如果你以前關注過MDD，那現(xiàn)在應該換個眼光來看待MDD。如果你從沒關注過MDD，那現(xiàn)在可是關注的好時機，因為工具支持已經(jīng)很成熟了。
MDD在工具集里有點兒與眾不同——就像你不會只使用一種語言，或是某種語言的單個庫，為了達到目的，你需要選擇合適的MDD方法和角度。如果想在項目中利用MDD，為了找到適合你的方式，你需要認真考慮下面的問題：
◆處于怎樣的情境？
◆對建模工具有什么需求？
◆對建模語言有哪些需求？
◆需要哪幾個抽象的層次？
◆如何簡化并自動化構建好的方案？
◆需要哪些類型的圖？需要多少個圖？
◆和誰進行溝通？他們要了解些什么？
◆如何確定MDD方法和工具能被整個團隊采用？
◆如何發(fā)揮整個團隊的優(yōu)勢，并讓每個人都參與進來？
◆問題空間里是否有現(xiàn)成的可用內容？
◆如何利用MDD來支持業(yè)務？如何利用MDD支持IT？如何利用MDD提供業(yè)務和IT編排？
◆有哪些可用內容？這些內容如何針對你的情況進行定制？
【編輯推薦】
