問題：我們當前為了安全性在做的一些軟件的形式化建模工作踱承，算是領域建模不？
這個問題可以和下面幾個問題一起回答：
“領域模型和我們的設計文檔里的架構設計圖有啥區(qū)別膀值？”
“領域建模最核心的是不是就是做好數(shù)據(jù)建模蚓耽？”
“模型驅動架構（MDA：Model-Driven Architecture）算是領域驅動開發(fā)嗎？”
先說答案：統(tǒng)統(tǒng)不是領域建模频祝！
補充一下：上面的回答是站在狹義的角度說的泌参。
讓我們先從更廣的角度討論一下軟件建模這件事脆淹。
建模是一個軟件設計活動，而軟件設計是為了長期低成本的實現(xiàn)需求沽一。所以建模服務于兩個目標：即讓軟件滿足需求和長期低成本盖溺。
軟件工程到今天，正確性（即滿足需求）的主要保證手段依然是測試锯玛！
還有另一種保證程序正確性的手段是“證明”咐柜，遺憾的是用“證明”保證程序正確性這件事到今天在工程化上仍然不是很成熟，有以下的限制攘残。
首先拙友，程序的編寫要滿足一定的約束（例如狀態(tài)不可變）或滿足某種數(shù)學形式化要求（例如必須抽象為有限狀態(tài)機集合）。這讓模型離業(yè)務域過遠歼郭，增加了編程的門檻遗契，同時增加了程序的理解難度和維護難度。
其次病曾，程序的證明也是run在計算機上的牍蜂，需要耗費大量的計算資源和時間，因此對于被證明程序的規(guī)模有要求泰涂，太大的程序難以在接受的時間內(nèi)得到結果鲫竞。為了效率經(jīng)常會將完整證明退化為只證明程序不會破壞某些約束或者不變式。
最后逼蒙，要認識到从绘，即使是經(jīng)過完整證明的程序也不能保證在現(xiàn)實環(huán)境中百分百的可靠。程序在和復雜的外部世界打交道的過程中是牢，不可避免會有“意料之外”的情況傳遞到軟件內(nèi)部僵井，讓軟件表現(xiàn)的不符合預期。這種“意料之外”是沒有辦法提前完全預測的驳棱，正確性的邊際成本只會越來越高∨玻現(xiàn)實的做法是為不同部分的軟件設定不同的承諾指標，然后采用不同的手段滿足不同的承諾社搅，從而讓整體的成本最低驻债。
目前采用形式化驗證的軟件，集中在對安全性要求高形葬、 被驗證部分的軟件規(guī)模有限却汉、且需求又相對穩(wěn)定的領域，比如航空荷并、駕駛合砂、醫(yī)療、通訊基礎設施等領域。而絕大部分在意成本又經(jīng)常修改的軟件翩伪，依然是采用測試來保證軟件滿足規(guī)劃的所有需求場景微猖。
讓我們再回到軟件設計的另一個目標，即“長期低成本”缘屹！
軟件成本主要由兩個方面組成：可理解性和可復用性凛剥。可理解性和可復用度高的軟件轻姿，變更和驗證的成本都會低很多犁珠。
因此，我們可以將軟件建模的目標大致的歸結為以下三個：
- 讓軟件更容易驗證其正確性
- 讓軟件更容易被理解
- 讓軟件的可復用度盡可能高互亮。
遺憾的是犁享，這幾個目標有的時候可能會有沖突。例如豹休，形式化建拇独ィ可以讓軟件自動化的被驗證，但是它需要將軟件建模為某種偏數(shù)學的形式化模型威根，于是軟件實現(xiàn)就會離業(yè)務的距離更遠凤巨，降低了軟件的可理解性。再比如為了讓軟件的可復用度盡可能的高洛搀，會為軟件增加非常多的抽象層敢茁，也會降低軟件的可理解性。
所以不同類型的軟件需要根據(jù)自己的特點留美，找到自己可接受的平衡點卷要。
而不同建模方法，瞄準的目標也是不同的独榴，軟件需要根據(jù)自己的平衡點，選擇和使用不同的建模方法奕枝。
如前文所敘棺榔，“形式化建模”主要瞄準的是軟件的正確性隘道。
再來看“數(shù)據(jù)建闹⑿”。它是從數(shù)據(jù)的角度設計程序谭梗，通過分析和抽象軟件中關注的數(shù)據(jù)概念忘晤、關系和完整性，并將其映射到對應的數(shù)據(jù)存儲模型上激捏。數(shù)據(jù)建模關注的是軟件的數(shù)據(jù)組織方式能否正確的完成功能设塔，以能否正確高效的映射到存儲模型上。數(shù)據(jù)建模有助于程序的正確性以及可理解性远舅。
遺憾的是“數(shù)據(jù)建娜蚧祝”沒有關注行為和數(shù)據(jù)之間的關系痕钢。而程序的“可復用度”要高的話，則需要按照高內(nèi)聚序六、低耦合的方式組織程序任连，讓行為和緊密相關的數(shù)據(jù)在一起，對外隱藏數(shù)據(jù)例诀，復用行為随抠。這就是“面向對象建模”做的事繁涂。它不僅考慮數(shù)據(jù)概念拱她、還關注行為概念以及它們之間的關系。面向對象建模不僅能提升軟件的可理解性爆土，還能提升軟件的可復用性椭懊。
而MDA（Model Driven Architecture）如之前的文章所述，試圖通過UML將面向對象建模標準化步势，使得模型可以脫離具體的實現(xiàn)技術被復用氧猬，以及提高模型到代碼之間的轉化效率。
還有另外一個和MDA屬于親戚關系的系統(tǒng)設計方法坏瘩，就是INCOSE(International Councilon Systems Engineering: 系統(tǒng)工程國際委員會) 提出的 MBSE(Model-Based Systems Engineering: 基于模型的系統(tǒng)工程)盅抚。
MBSE是INCOSE覺得OMG(Object ManagementGroup) 搞的UML和MDA對于系統(tǒng)工程來說不夠嚴謹，于是自己搞了一套系統(tǒng)工程方法論倔矾。MBSE包含建模語言妄均，建模工具和建模方法等一系列相對完備的方法和過程，在整個流程中要求以嚴謹?shù)哪Ｐ万寗釉O計過程哪自。
MBSE的建模語言為SysML丰包，它是基于UML2.0上做了增減，主要是增加了更適合系統(tǒng)需求工程的需求圖以及可用于性能分析和定量分析的參數(shù)圖壤巷。目前該方法主要用于對安全邑彪、性能要求比較高的軟硬件結合類產(chǎn)品中，例如汽車工業(yè)以及其它實時嵌入式軟硬件產(chǎn)品等胧华。
MBSE的建模流程是比較厚重的寄症，多個階段模型按照階段轉化求精，對于交付節(jié)奏快的軟件產(chǎn)品有些笨重矩动。另外MBSE中的模型主要是面向系統(tǒng)設計和前期驗證有巧，并不側重于直接指導代碼開發(fā)课幕。
最后我們來看領域驅動設計里的“領域建氖瞿牛”。領域建模的目標是用于在限定范圍內(nèi)建立一個業(yè)務專家和開發(fā)團隊能達成共識的軟件模型锰霜，用于指導軟件實現(xiàn)并保持概念一致性，降低溝通成本柑潦。領域建模是在軟件可理解性和可復用性中間找到一條工程和技術上可行的平衡點享言。
如我們之前的文章所書，領域驅動設計給領域建模提了目標渗鬼，給了若干建議览露，但是并沒有限定采用哪種具體的建模技術，只要能達到它所設立的目標就行譬胎。這給了它極大的擴展空間差牛，也正因如此這門技術現(xiàn)如今被社區(qū)發(fā)展得似乎“無所不包”。
不過通過前文分析堰乔，我們還是能看到“形式化建钠”、“數(shù)據(jù)建母浜睿”侦讨、“面向對象建模”和“MDA”瞄準的目標和領域建模的目標都不盡相同苟翻，所以從狹義的角度說韵卤，上述建模都不是領域建模。
但是遠近親疏畢竟還是有所不同崇猫，領域建模更多的還是會采用面向對象建模沈条，是因為相比之下面向對象建模更成熟和系統(tǒng)，更能接近領域驅動設計所追求的目標诅炉。
不過蜡歹，領域驅動設計強調(diào)在軟件分析、設計和實現(xiàn)階段只存在一個模型涕烧，這個模型要能橋接業(yè)務專家和軟件開發(fā)團隊月而，聯(lián)通問題域與解決方案域。因此“領域模型”更偏向于面向對象中的“分析模型”與“設計模型”的融合模型议纯。
我在工作實踐中應用領域驅動設計父款，是因為它提倡建模工作以領域為核心，以在代碼中落地為目標痹扇，能夠兼顧業(yè)務和實現(xiàn)。具體到建模方法上雖然以面向對象建模方法為核心溯香，但也會經(jīng)常借鑒或使用其它方法鲫构。畢竟好的設計是一種平衡，任何方法都是工具玫坛！
最后结笨，以模型作為分析設計工具，驅動軟件開發(fā)的方法，有個統(tǒng)稱叫做“模型驅動開發(fā)”（MDD Model-Driven Development炕吸，注意伐憾，不是MDA）。面向對象建模赫模，MDA树肃，領域建模都可以認為是模型驅動開發(fā)。許多形式化方法支持以圖形化或者DSL(領域特定語言)的方式建模瀑罗，也支持代碼自動生成胸嘴，號稱自己是模型驅動開發(fā)，是沒錯的斩祭。
還漏了一個問題：“領域模型和我們設計文檔里的架構設計圖有啥區(qū)別劣像？”
答：如果你們設計文檔里面的架構圖是業(yè)務專家和軟件開發(fā)者之間的關于軟件如何解決業(yè)務問題的模型共識，并且和代碼保持一致摧玫，那么就是領域模型耳奕。如果僅是為了演示、或者劃分軟件功能模塊诬像、定責任田屋群，那很抱歉，不是領域模型颅停。
