近日，在Gervas Douglas的SOA郵件討論組的OO和SOA兩大陣營間展開了一場討論，探討的話題包括領域建模（Domain Model）、消息格式和服務設計等。討論結(jié)果得出了幾條適用于大多數(shù)SOA實施的重要原則：

• 面向服務的建模技術，譬如DOSOM（面向領域的服務建模），是識別候選業(yè)務服務的第一步，此處領域是根據(jù)業(yè)務的功能結(jié)構(gòu)清晰地劃分的。
• 定義完業(yè)務服務契約（Contract）之后，OOD是設計服務實現(xiàn)的理想方法。
• 通過MDM（主數(shù)據(jù)管理）技術，通過定義最小的規(guī)范模型，使服務之間需要交換的信息量盡可能地少。

　　整個討論因Kirstan Vandersluis在討論組的一則有關領域建模的發(fā)問而引起的，關于實現(xiàn)企業(yè)消息格式標準化的問題，雖然他自己有下列三種考慮，但是在提問中他想得到思考此類問題的通用原則。

1.基于外部消息標準（該行業(yè)的標準是MISMO）來構(gòu)建內(nèi)部消息格式。雖然此消息集合很臃腫，但它是成熟的，支持大多數(shù)業(yè)務域，并且具有擴展性，可為該公司及其流程擴展一些特有的屬性。
2.根據(jù)企業(yè)數(shù)據(jù)模型創(chuàng)建一個基于XML的消息集合。該公司在企業(yè)數(shù)據(jù)模型上已經(jīng)投入了很大資金，其模型已經(jīng)包含了業(yè)務所需的絕大多數(shù)屬性。籠統(tǒng)地說，我們已經(jīng)通過ER Studio中生成了XML模式，并將對此模式基礎上進行調(diào)整以定義消息負載（payload）。
3.將MISMO主要用作實體的定義，然后簡化其結(jié)構(gòu)以提高使用性。我們可利用MISMO豐富的通用詞匯，但在接下來的幾年里我們可能需要定義出幾十種交易的消息格式，而它們在MISMO中已經(jīng)定義了。

　　Steve Jones給出了回復，分享了其本人在SOA信息建模方面的經(jīng)驗以及他所觀察到的三點心得：

• 行業(yè)標準（比如MISMO）適用于與同行業(yè)的外部合作伙伴之間的通信
• 規(guī)范模型，只有在內(nèi)部使用、交互場景不經(jīng)常變化、并且實體不在多個業(yè)務域間共享的情況下才是適合的。
• 對于大多數(shù)企業(yè)內(nèi)部的場景，都是為可變性和靈活性而設計的，換言之，通過MDM共享業(yè)務實體并維護盡可能少的規(guī)范模型。這樣做同時避免了一個陷阱——為妥協(xié)企業(yè)內(nèi)的某個行業(yè)之外的應用（比如HR）而擴展行業(yè)標準的做法。

　　Ashraf Gulal從OOD的角度分享了他的觀點：

領域數(shù)據(jù)是一些類（class），它們封裝了實現(xiàn)服務所需的信息。這里應該使用經(jīng)典的對象/關系映射（ORM）方法。

　　對此，Steve Jones回復：

ORM與服務語義（semantics）或SOA一點關系也沒有，而且“領域數(shù)據(jù)是一些封裝了實現(xiàn)服務所需信息的類”的提法也稍顯隨意。數(shù)據(jù)和類是完全不同的兩個事物，一個是結(jié)構(gòu)化元素（類），而另一個則是實例（數(shù)據(jù)）。

　　而David Tildesley則支持Ashraf Gulal的OOD方法，他說：

我比較贊同Ashraf的觀點——將OO的設計原則（封裝、松耦合、重組合輕繼承）應用于SOA。正是因為這些原則被人們丟棄了，才導致了SOA項目以及應用開發(fā)走向失敗及混亂的局面。

我推薦Coad和De Luca等人的建議，使用四種顏色的建模原型和原型域圖形（archetype domain shape，ADS，又稱領域中立組件，domain neutral component或DNC），這是久經(jīng)驗證的技術/模式。ADS將提示你，那些松耦合的邏輯組件（一組類）將變成“實體”服務，它們將成為“業(yè)務組件”，而且，從這里生成XSD（避免XSD限制、將一切設置成可選的、通過import和include合理地打包）也是相當直觀的。你的SOA消息就是CDM的視圖，其中包含業(yè)務組件以及其他與SOA基礎設施相關的元數(shù)據(jù)/上下文。每個業(yè)務組件的中心有一個核心實體（粉色或綠色圖形）。解耦點位于角色（黃色圖形）上面。

揚SOA（包含某些指導原則的方法）抑OOA對我而言是徒勞的——這好比在傳統(tǒng)的三層應用架構(gòu)中將UI與“OO”比較一樣。為了達到CDM和候選服務列表，SOA執(zhí)行者完全可以自由地選擇OO的設計實踐、模式和技術或其他方法。

　　Michael Poulin和Steve Jones都不同意使用這種方法來識別候選服務和實施領域建模。Michael Poulin的回復提到了幾個要點：

SOA是一個功能性模型，不是對象模型。僅此而已！正因為如此，在設計時，需要特別地關注模型，因為功能模型更加接近于人的行為，并且附帶了一些以技術為中心的OO方法所不能承載的信息。

當你做容器設計時，第一步不是OO或DDD（領域驅(qū)動的設計），而應該先DOSOM，而后才是OO/DDD。

　　Steve Jones這樣總結(jié)：

對于服務，我提倡使用SOA方法來創(chuàng)建清晰劃分的領域，然后使用諸如MDM之類的技術來創(chuàng)建盡可能小的規(guī)范模型，這樣可以減少服務交換所需的信息；而對于單個應用并且這些服務都是緊耦合、高內(nèi)聚的情況，以OO為中心的方法則可能是更好的選擇，而且確實可行，不過，對于跨多個業(yè)務領域或組織的情況，這種做法就不可行了。

業(yè)務架構(gòu)，使用SOA；實現(xiàn)服務和基于最少量信息交互（而非CMD）的信息交互模型，使用OO。

　　David Tildesley從MDM的角度總結(jié)了該討論，他引用了一個Steve Jones確認的適合于使用MDM的場景：

應該可以這么說，MDM關心的是通過創(chuàng)建“XREF”，為customer建立一個統(tǒng)一的視圖——當有多個應用（它們往往位于不同的業(yè)務線）且每個應用各自擁有其自己的customer視圖時才需要它。MDM告訴我們A系統(tǒng)中的“Thomas J. Smith”和B系統(tǒng)中的“Tom Smith”到底是不是同一個人，并且它在每個應用中維護了指向?qū)嶓w的外鍵引用。

　　查看英文原文：OOD vs SOA Approach to SOA Domain Modeling

it知識庫：SOA領域建模，用OOD還是SOA方法？，轉(zhuǎn)載需保留來源！

鄭重聲明：本文版權(quán)歸原作者所有，轉(zhuǎn)載文章僅為傳播更多信息之目的，如作者信息標記有誤，請第一時間聯(lián)系我們修改或刪除，多謝。