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

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

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

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

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

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

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

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

　　對此，Steve Jones回復：

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

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

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

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

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

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

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

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

　　Steve Jones這樣總結：

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

業務架構，使用SOA；實現服務和基于最少量信息交互（而非CMD）的信息交互模型，使用OO。

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

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

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