需求分析之业务模型

数据和事件分开

先从Peter的数据和事件分开说起，Peter找了李福华讨论了返运的需求实现，他的建议是将库存和返运关系分离开来，即数据和事件分离开来：不要让（事件）状态污染数据，对于正常入库、调拨入库这属于原生态状态（Native Status）没问题，对于返运这种后天事件导致的状态就不要用来污染数据，而是单独页面承载操作，单独表结构来存储状态；我是深以为然；如果这样，出库是否也应该分离出来呢？库存表是否只是保存库存信息，表明库存还有多少多少，也属于"Native Status"，我倒是觉得没必要分离。

需求高级分析三板斧

核心对象（最小业务单元，BU）都是什么，核心对象字段都有什么（客户提供，还要考虑关联字段）；业务对象间关系都是怎样的（二元关系如何1:1还是1：*，通过什么进行关联）；和业务外对对象关系是怎样的；业务流程是怎样的，都有哪些"约束"；该业务的目的以及产生的对象后续影响有哪些（产生的数据将会被怎样使用）；分析的重点是在业务流程以及对象关系层次；

需求详细分析三板斧

详细分析很大程度原型已经出来，此时考虑的盘子就是页面，页面有哪些状态，每种状态都有哪些数据？数据本身有几种状态（比如，提交，未提交）；起点就是"操作"（动作），分析的重点字段（页面状态就是为了分析字段做准备的）；比如返运的时候，修改的是库存数据，OK，库存数据都用来干嘛？用来出库的，出库都干那些事情？调SAP接口；库存减少...一走，其实很多问题就解决了；

就是做需求其实不断地在画一个有一个的圆，一定要保证新添加进去的数据是可以画圆整个需求的。

 

什么是业务模型

杜工在周会上面提出了对于入库信息而言，调拨、正常入库其实是并列的；但是我们现在是把内容都捏在了一起，还没有加以区分，比如批次号，对于调拨以及正常入库其实是允许他们重复的；但是我觉得这个业务模型渐渐的有了意识，就是分类流程，当然在数据库物理存储上可以放在一张表里面，但是在理解和规划的时候，一定要有一种划清楚各个独立主题的概念；

业务由两部分组成：数据和过程。业务的结果是数据（核心数据），业务的过程却是独立的，比如入库包含调拨的业务和正常入库的业务，发放控制的出库以及调拨的出库，尽管他们都是入库/出库（在物理存储结构是一致的），但是他们确实并列的，彼此平行的，这在物理存储上的表现就是通过一个字段来做区分，业务层（Application层）处理上却要各自分开，保持彼此的纯洁性。

这意味着，回到了之前考虑，对于任何功能点要"认祖归宗"，一定要找到一个归属的大类（如果确实没有，那么就新建一个）；然后再大类下面寻找并行同类；这样在逻辑上（模型）做到了分离，在代码实现以及数据库设计上面也彼此独立，做到了比较好的"干净"的关系，正所谓"君子群而不党"。

那么，就出来的，业务模型本质其实是针对业务的"过程"部分，针对过程进行归大类，分离出独立过程单元体（Dependency Process Unit，DPU），并针对每个独立的DPU进行生命周期设计，这就是业务模型的建立。