这里指的对象是从业务视角观察的对象，如订单，产品，合同，顾客都是一个典型的业务对象，我们关心的也是如何对订单这个业务对象进行建模。

　　系统一般采用关系型数据库来实现了数据的持久性机制，所以存在了面向对象的模型和关系模型间的转换和映射问题。对于小型系统可以直接机械的将面向对象模型转换为关系模型。但对于大型系统这个问题需要进一步考虑。

　　1.继承关系

　　业务对象间也存在父对象和子对象的关系。对于继承关系的映射关注的问题主要有两个，一个是对于父对象是否要单独映射相对应的数据表;另一个是对应不同类型的子对象是否都需要单独建立相关的数据表。都单据映射数据表可以最大限度减少数据冗余，满足范式的要求，但会带来关系查询和对象操作的复杂性。

　　企业业务对象应该在高层进行抽象，如该业务对象是否需要启流程?该业务对象是否需要进行版本控制?通过这种抽象后应该剥离出流程和版本控制基对象，同时数据库应该有相对应的数据表。这样的好处就是系统中所有需要流程控制的业务对象以及对象的实例信息都可以在同一个数据表中快速检索到，方面流程方面功能的系统实现。

　　2.关联关系和引用关系

　　关联关系在业务对象建模中最为常见，这也是最容易进行对象和关系映射的。

　　如订单和订单明细间是1对N的关联关系,我们关注的订单实体虽然是一个业务对象，但通过映射后会对应到后台的两张或多张数据库表。

　　关联关系必须相关的对象和数据项都是业务对象信息的一部分，随业务对象存在而存在，关联的明细对象一般都需要映射专门的数据表。

　　订单头需要引用顾客的信息，这是1:1的关系。在这里看到仅仅是订单头要引用顾客对象，而顾客对象是在其它地方进行的业务对象定义。这里在订单对象上面也仅仅存储关系，没有任何信息会存储在这个引用关系上面。所以这种引用关系的映射仅仅会是在订单头数据表增加相关的外键即可实现，而不需要单独增加数据表。

　　3.关于代码表和基础数据

　　例如订单类型，发运区域，付款方式等数据项，都需要通过代码表的方式进行处理。所以代码表应该是已经经过抽象的一个比较特殊的业务对象。通过代码表的设计，可以解决大多数枚举型数据项对数据的要求。

　　另外一些基础数据是常说的不涉及到流程，权限和业务操作的数据对象。如单位信息对象，用户信息对象。这些对象都是属于系统的基础信息存在，其本身不涉及到流程和业务处理，更多的是为其它业务对象提供服务。

　　在对象建模过程中，将业务对象和业务操作进一步分离，这样业务对象可以作为实体和DTO来使用，便于相关的分布式计算和处理。业务操作也可以转换为设计和实现中单独的控制类，达到进一步的解藕。

　　某个业务对象建模过程中存在主体对象和关联引用对象的概念。主体对象是操作中需要进行存储和更新的对象，如对于订单对象的订单头和订单明细信息属于主体对象。而顾客，商品等在订单对象建模过程中就不属于主体对象，仅仅是查询和检索时候需要附属查看的相关信息。

原文转自：http://www.ltesting.net