SOA领域建模，用OOD还是SOA方法？

作者 Jeevak Kasarkod 译者 马国耀 发布于 2011年4月7日

领域

企业架构,

运维 & 基础架构,

架构 & 设计

主题

Domain-Driven Design ,

SOA ,

设计 ,

方法论 ,

面向对象设计 ,

编程 ,

企业架构 ,

架构

分享到

近日，在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”到底是不是同一个人，并且它在每个应用中维护了指向实体的外键引用。

译者 马国耀 关注企业级应用开发与架构，有多年SOA项目实施和咨询经验，专注于SOA及云计算的融合。

相关厂商内容

保持某些系统的高可用性，是一些企业的重中之重，如何设计？

海量数据处理，海量视频分发，架构热点难点，尽在架构师峰会！

相关赞助商

ArchSummit全球架构师峰会报名启动！7折优惠，5月31日截止！

1. 返回顶部

   没人讨论？

   发表人 Peng Sunny

   翻译得不错，我关于本文的理解见：www.jdon.com/jivejdon/thread/40576
   欢迎讨论。
   
   btw:好像chrome不能点按回复按钮，更换IE就可以了。

   回复

2. 返回顶部

   Re: 没人讨论？

   发表人 马 国耀

   我个人比较赞同Steve Jones的观点。我在最近的一个SOA实施过程中，而且两种方法都用到了。
   
   我们的方法不是先使用SOA方法进行服务发现，后在服务实现过程中使用DDD，而是meet-in-the-middle.
   
   在服务发现时，我们使用SOMA方法论，对于DDD，我们使用企业信息模型建模，分析概念信息模型、逻辑信息模型、和物理信息模型。
   
   实现服务时就是二者结合之时。

   回复