这样的对象能叫“实体”么？

很多企业级的应用还是基于数据库的事务性操作，至少我遇到的是这样的。一般在一次业务操作开始时候，会建立很多业务对象，之后开始具体的业务操作，操作完成后，数据会被及时更新到数据中，之后这些业务对象被清理掉。
这样，我们建立业务对象往往不会存在“状态”（内存中）这样的概念，只是作为一个数据的临时包装，用过之后数据被保存到数据库中，但是着这样的业务对象往往是很有业务价值的。“实体”的一个主要特征是有标号和状态，但是上面的业务对象可以说没有内存级的状态。还能叫作“实体”么？

如果基于内存开发业务系统（企业级应用应用网游等实时类的系统除去），也就是实现所谓“真正意义上”的“实体”，那么技术成熟么？可行性怎么样?如果我们不把数据及时存触，那么内存数据丢失了怎么办？为了解决丢失又会引出一大串的技术。但是如果把数据每一次都存到数据库中，那么就成了数据库核心了，所有的压力瓶颈又在数据库，性能的提高成了又一个瓶颈？又该如何是好呢？

就以一个图书馆借书这个业务来作比，在这个需求中图书应该是“实体”，每一本书都必须有唯一标号，同时每一本在借阅过程中会有状态的概念，虽然该状态不一定在图书这个“实体”上，如“空闲”，“借阅中”，“需归还”等等。我认为在进行借阅这个动作中，完成后需要将图书更新到数据库，因为接下来的动作的发生是在若干时间后，而不是马上发生，如果在内存中的话，这个“实体”就太可怜了，不知道要等到什么时候，可能花都谢了。但是在进行系统分析设计的时候，也应该按照实体来定义，而不能算是值对象（我理解值对象可以是在业务场景中公共信息部分、传送的消息）
如果在网游中，所有的业务对象就和“实体”的概念一致了。所有我想说“实体”对象应该是逻辑概念，在不同的场景不同需求下“实体”对象的定义应该是有所区别，但是根本就是这个“实体”应该是核心领域中的对象，在核心领域中他是有标识和状态的，只不过是分内存级表示还是持久层级表示了。

就是不知道自己想的对不对，请各位大师指正。