仓库区域结构设计
类型上分为Location、Area、Section三种。Location映射到某个仓储地点、工厂；Area映射到各种存货区域；Section映射到存货区域中的货架、细分的存储单元
Area允许建立父子关联关系，可以用Area映射到待检区、退货区、合格区这样的业务概念，还可以在Area下面建立子级Area，例如在合格区下面按产品主类再细分区域
移动类型的设计
主要目的：
对各种出入库行为分门别类，用这个统一的标准对出入库行为进行管理，记录、追踪、分析。例如象SAP一样：101表示采购收货、103表示采购收货到GR冻结区、124表示从GR冻结区退货给供应商
其它目的：
移动类型不在代码中硬编码，通过配置进行管理；移动类型能够用来代表不同的业务行为，以后通过配置可以对它代表的业务行为进行更换；与各种出入库单据之间的关系是个疑问点；各种移动类型可以使用的仓库区域进行配置，这样仓库区域映射的业务概念也不是硬编码，而可以通过配置进行调整改变
出入库单据与库存交易的设计
a) 考虑了2种做法
1. 出入库单据和明细就直接作为库存交易
2. 出入库单据和明细，与库存交易分开
方案1主要是考虑出入库单据和明细所包含的主要信息，与库存交易基本一样；但考虑到各种出入库单据本身可能有不同的状态转换形式、有签核流程、有其它不同的附加属性等，还是采用方案2将它们分开。交易表记录的就只是库房已经完成的交易，不会与其它逻辑混在一起
b) 各种类型的单据都定义了单据类型，依附于单据类型产生的一些配置包括：单据号码生成规则、单据签核流程配置、单据状态定义、单据需要执行的交易步骤以及每个步骤中采用哪种交易类型的配置
疑点
1. 各种出入库单据能否统一起来，如何统一？
2. 出入库单据类型与交易类型之间的本质联系是什么？方案上是否可以优化？
3. 仓库区域、交易类型、各种出入库单据组合起来，是否可以完全达到可配置这个目标，怎样设计？
疑点解释2008.07.30:
出入库单据是基于用户使用方面考虑的设计，例如仓库的实际作业流程是什么状况，有哪些行业特性、管理差异等。出入库单据就是把这些情况都考虑进来，尽可能合理、方便的配合用户作业操作
交易类型完全是后台的实现规则，主要作用是管理、实现出入库交易的核心逻辑；实现与成本、财务相关科目、事件的整合。所以单据类型与交易类型之间存在组合映射关系；交易类型标识了一组事件接口，包括出入库交易逻辑、成本财务事件处理逻辑
出入库单据只是一套衣服，我们应该能够脱下一套换成另外一套。针对单据类型设计的配置，主要用来满足业务流程操作的灵活性，例如单据状态怎么流转、是否需要签核、单据针对哪些物料类型进行操作等等。而针对交易类型设计的配置，则更侧重于企业整体运作流程、行业区域特性等等
分层次来看一下，最终的业务操作人员负责单据的录入、提交，以及单据流程中的一些其它事件处理；客户企业的管理者、系统管理员能够对系统做一些配置设定工作，即维护单据类型相关的配置，这些配置设定主要影响业务操作人员的作业流程等层面的东西；顾问实施公司、软件开发企业的系统初始化设定，核心是维护好交易类型相关的配置
2008.07.18
恰当的设置冗余字段，注意并发时的一致性、死锁问题，可以避免大部分复杂查询，对数据库性能利大于弊
2008.07.22
JCP, NHibernate的做法都是顺理成章的，缓存、Unit of Work，Dynamic Proxy实现的延迟加载、对象和属性dirty的判断以及只更新dirty部分，并发控制机制等等，都是必不可少的特性。对缓存的并发控制带来其它的概念，例如把session作为隔离边界，缓存对象需要lock机制，同时为了支持Unit of Work特性，缓存的对象必须加上版本控制，对工作单元commit时进行版本判断。一路做下来，这些机制自然而然跟NHibernate没有多少差别了。
2008.07.30
库存交易其实和财务、银行交易本质上没有区别：
当前和历史库存量对应银行帐号余额和余额变化的历史记录；
财务的各种科目对应到不同的交易类型，科目数据对应库存交易数据，科目数据的原始凭证对应触发库存交易的各种单据；
财务流、现金流在库存交易中体现为物流，用复式记帐法来解释，物流也不会凭空产生或消失，只是从一种状态、形态转换到另一种状态、形态。只是库存交易不需要如此严格的按照财务系统方式设计，例如采购入库可以理解为贷记在途量(或订货量、供应商物资资产等)，借记仓库库存量。这种严格的借贷关系被转移到成本模块、财务系统处理，出入库本身的事件记录作为这些系统的原始或引用凭证；