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