如何抽象资产，现实中可以对应一个商品。
商品可能最开始在一个京东仓库，京东还会有二仓，或者临时快递点，这时候就会设计出库和入库的过程。
如果用传统方式来写，会发现有个方法用来表示从总部到二仓，购买的时候又会调用一次。
对于资产来说（可以是商品，也可以是虚拟商品），从头到尾只有入库和出库两个操作。
通常，用一个状态值来描述出和入的动作。
出实际上就是这个商品在仓库中不能用了，将来如果退回来，又是可用了。
这就是领域对象的充血模型，我们在分析对象自身的行为动作。
如果入库了，就发布一个商品入库的事件。
对于单个商品来讲，我们是入库，然而在显示生活中，可能有一批商品入库。
InOutBizType 是业务行为的描述。
对资产来说，不关注谁进行了操作，所以可以发送一个事件。
注册事件后，会有一个事件监听器。
商品入库后，要添加出入库记录、更新库存、记录资产编码。
未来想要增加一个新的功能，就需要改资产的代码，这违背了开闭原则。
这里就需要领域开发中的概念：事件解耦。
最小知道原则：知道的越少，方法就越通用。
对于资产，无论是现实生活中资产的调拨、购买等。
领域服务分为应用->领域服务层。
领域服务是对所有业务的抽象，无论上层怎么变，
所有出库入库都不是集体行为，而是单个行为。
每次单个出库入库都会发送一条事件，如何保证在批量出入库的时候不发送那么多的事件。
单个的行为累计到一起形成批次的概念，要考虑每一个都有单独的行为。
领域服务就是在应用层下提供一个抽象的更通用的服务。
数据库设计方面：
assert 存储库内资产：
assert_in_out_record 存储出入库记录：
入库的操作对应一个用户，但是对于资产来说，却没有对应任何一个用户。
assert_life_cycle
主要记录某一个资产出入库的所有记录。
可以用来进行生命周期的跟踪。