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。
对于服务，我提倡使用SOA方法来创建清晰划分的领域，然后使用诸如MDM之类的技术来创建尽可能小的规范模型，这样可以减少服务交换所需的信息；而对于单个应用并且这些服务都是紧耦合、高内聚的情况，以OO为中心的方法则可能是更好的选择，而且确实可行，不过，对于跨多个业务领域或组织的情况，这种做法就不可行了。业务架构，使用SOA；实现服务和基于最少量信息交互（而非CMD）的信息交互模型，使用OO。
David Tildesley从MDM的角度总结了该讨论，他引用了一个Steve Jones确认的适合于使用MDM的场景：
应该可以这么说，MDM关心的是通过创建“XREF”，为customer建立一个统一的视图——当有多个应用（它们往往位于不同的业务线）且每个应用各自拥有其自己的customer视图时才需要它。MDM告诉我们A系统中的“Thomas J. Smith”和B系统中的“Tom Smith”到底是不是同一个人，并且它在每个应用中维护了指向实体的外键引用。