SOA领域建模,用OOD还是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”到底是不是同一个人,并且它在每个应用中维护了指向实体的外键引用。

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

你可能感兴趣的:(SOA,OOD,领域建模)