在销售订单应用里，最容易被低估的一件事，是一张订单在界面上看起来像一个完整对象，落到数据库里却往往不是一条记录。订单抬头保存客户、销售组织、订单日期、交易货币和总金额，订单项目保存物料、数量、单价、工厂和交货日期。一个抬头下面可能挂着几十个项目，项目还可能继续关联产品、计量单位、定价条件和合作伙伴。界面里的一个 Sales Order，到了持久化层便成了多张数据库表、多组主键和多条关联关系。Draft 又让这个结构多了一层难度。销售人员正在录入一张包含四十个项目的海外订单，已经维护完客户和货币，项目只录到一半，此时浏览器关闭，或者临时切换去处理另一项工作。系统不能把这张不完整的订单直接写入正式业务数据，也不能让已经录入的内容全部丢失。更合理的处理方式，是让正式订单继续保存在 Active Persistence 中，把尚未提交的修改保存在 Draft Persistence 中。等销售人员重新进入应用，再恢复未完成的编辑状态。所以，定义 Sales Order 的 Draft Business Object，不能只理解成给 CDS 加一个草稿开关。真正需要建立的是一条连续的模型链路，数据库表负责保存数据，CDS Business Object View 负责描述业务对象结构，@ObjectModel注解负责补充事务语义，BOPF 根据这些元数据生成可运行的业务对象，而 Draft 机制再借用同一套业务对象元数据生成草稿实体。SAP 官方文档也明确指出，事务型 SAP Fiori 应用的持久化模型由数据库表和其他 ABAP Dictionary 对象组成，每一个 Business Object CDS View 都需要对应的数据源，Business Object View