SOA中的业务对象建模

谈到SOA项目的实施，必定会涉及到大量的建模过程。目前建模的方式可以分为自顶向下方式和自底向上方式，两种方式适合不同的情况：如果实施SOA的企业从基础开始从新构造信息系统，自顶向下的建模方式，从业务流程开始逐步抽象，最终产生架构，更容易从全局和战略的角度规划整个信息系统蓝图；而大多数SOA项目是“进化”型的，是在运行企业现有业务的信息系统中逐步引入这种面向服务的新软件系统架构，这时候从自底向上的建模方式开始能够更容易发现现有业务中能够聚合成服务的业务对象（Business Object），从而快速构建新的应用，让SOA项目尽快产生效益，激励士气并促进SOA实施的深入推广。所以从具体操作层面，做好SOA中的业务对象建模非常关键。这里就SOA实施中的业务对象建模，聊一点看法。

在《建设企业级SOA大厦》一文中提到的构建企业级SOA的四个步骤，第一步工作就是巩固基础 (Solidify Your Foundation)，为构建企业级SOA，首先要巩固基础，也就是准备企业信息平台和基础信息架构，这个阶段的关键是主数据管理。从企业业务信息平台角度去理解这里提到的“主数据管理”，业务对象建模是其中的重要内容。因为在面向服务的架构中，为企业带来效益的是服务复用和集成，那么在企业部署面向服务的架构的时候，第一个问题恐怕就是“有什么样的服务我们可以复用和集成”。为了给出正确的答案，最好的方法莫过于对企业潜在的业务应用系统做一个调查，调查的目的就是为把现存的信息系统“主数据”如同企业的其他资产一样管理起来。这种调查通常就是一个自底向上的建模过程，而建模的基本单元就是业务对象，例如：物料、主生产计划、订单，发货单、发票等等。

为什么是基于业务对象建模而不是针对业务流程呢？因为业务流程由业务对象功能聚合而成，相对于业务流程的易变，业务对象相对稳定，引进面向服务的架构就是为了在稳定的业务对象上构建更为灵活的业务流程。业务对象建模如何开始呢？你可以从企业信息系统建设中形成的需求和设计文档着手，对其中描述的业务对象归纳总结，特别如果你使用SAP系统，系统的业务对象知识库（Business Object Repository）就是最好的起点。打开在SAP系统业务对象知识库，每个系统中的业务对象都有一个完整的模型描述，涵盖业务对象的主键（Key Fields）、接口（Interfaces）、属性（Attributes）、方法（Methods）、和事件（Events），所有这些都会决定业务对象可能提供的可重用的服务和集成接口。这种模型描述也可以被企业中SAP以外的系统参照，从而产生一致的业务对象模型。最不幸的情况是没有任何可以参考的材料，对业务对象的建模会变得非常艰难，虽然如此，这项工作也要从基础开始做，权且算是偿还过去信息系统建设的欠账。原有企业信息系统中业务对象模型之类“主数据”的完备与否，很大程度上决定了实施SOA的初始成本，额外的成本往往是由历史欠账造成的。

业务对象模型建立之后，作为SOA资产的内容有一个长期管理维护的过程，可以建立业务对象模型的知识库，作为开发服务，内部和外部服务引用的依据。例如：SAP正在定义的企业服务知识仓库（Enterprise Service Repository）就有这样的作用。

设想一下业务对象建模在项目中的具体场景：