数据和事件分开
　　先从Peter的数据和事件分开说起，Peter找了李福华讨论了返运的需求实现，他的建议是将库存和返运关系分离开来，即数据和事件分离开来：不要让（事件）状态污染数据，对于正常入库、调拨入库这属于原生态状态（Native Status）没问题，对于返运这种后天事件导致的状态不要用来污染数据，而是单独页面承载操作，单独表结构来存储状态；我是深以为然；如果这样，出库是否也应该分离出来呢？库存表是否只是保存库存信息，表明库存还有多少多少，也属于"Native Status"，我倒是觉得没必要分离。
　　需求三板斧
　　核心对象都是什么，核心对象字段都有什么（客户提供，还要考虑关联字段）；业务对象间关系都是怎样的（二元关系如何1:1还是1：*，通过什么进行关联）；和业务外对对象关系是怎样的；业务流程是怎样的，都有哪些"约束"；该业务的目的以及产生的对象后续影响有哪些（产生的数据将会被怎样使用）；
　　什么是业务模型
　　杜工在周会上面提出了对于入库信息而言，调拨、正常入库其实是并列的；但是我们现在是把内容都捏在了一起，还没有加以区分，比如批次号，对于调拨以及正常入库其实是允许他们重复的；但是我觉得这个业务模型渐渐的有了意识，是分类流程，当然在数据库物理存储上可以放在一张表里面，但是在理解和规划的时候，一定要有一种划清楚各个独立主题的概念；
　　业务由两部分组成：数据和过程。业务的结果是数据（核心数据），业务的过程却是独立的，比如入库包含调拨的业务和正常入库的业务，发放控制的出库以及调拨的出库，尽管他们都是入库/出库（在物理存储结构是一致的），但是他们确实并列的，彼此平行的，这在物理存储上的表现是通过一个字段来做区分，业务层（Application层）处理上却要各自分开，保持彼此的纯洁性。
　　这意味着，回到了之前考虑，对于任何功能点要"认祖归宗"，一定要找到一个归属的大类（如果确实没有，那么新建一个）；然后再大类下面寻找并行同类；这样在逻辑上（模型）做到了分离，在代码实现以及数据库设计上面也彼此独立，做到了比较好的"干净"的关系，正所谓"君子群而不党"。
　　那么，出来的，业务模型本质其实是针对业务的"过程"部分，针对过程进行归大类，分离出独立过程单元体（Dependency Process Unit，DPU），并针对每个独立的DPU进行生命周期设计，这是业务模型的建立