SOA领域建模,用OOD还是SOA方法?
2013-08-17 03:04
267 查看
近日,在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
http://www.infoq.com/cn/news/2011/04/soa-domain-modeling-debate/
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
http://www.infoq.com/cn/news/2011/04/soa-domain-modeling-debate/
相关文章推荐
- SOA领域建模,用OOD还是SOA方法?
- 领域建模的思想和方法
- 领域建模的思想和方法
- 面向服务体系架构的业务规划和建模方法系列之五——SOA项目中IBM产品的采用 推荐
- 领域建模的思想和方法(转)
- 领域建模的思想和方法
- SOA/SCA是作为商业领域的建模的构架,只不过技术人员理解到技术层面了
- 面向服务体系架构的业务规划和建模方法之六-SOA项目的导入策略 推荐
- HENXU-SOA的业务规划和建模方法之八——组件化业务模型(CBM)介绍 推荐
- 领域建模有很多种方法,对于同样的问题域使用不同的建模手段得到的模型可能也不尽相同。于是我经常听到这样一个问题:怎么才能保证建模的正确性?
- SOA设计模型类型及建模方法
- 领域建模的思想和方法
- 领域建模的思想和方法(转)
- HENXU-SOA的业务规划和建模方法之七——SOA的方法融合 推荐
- 领域建模的思想和方法
- 面向服务体系架构的业务规划和建模方法系列之三--SOA方法裁减样例 推荐
- 领域分析与UML建模方法_初阶
- 数学建模方法大全
- 数据仓库建模方法
- 【Java面试题】42 TreeSet里面放对象,如果同时放入了父类和子类的实例对象,那比较时使用的是父类的compareTo方法,还是使用的子类的compareTo方法,还是抛异常!