下一代信息系统建设的思考

OO模型的缺陷是把信息系统理解为现实世界的映射。但基于OPM的模型，则将现实世界和信息世界融为一体。所有的一切都是Object 和 Object 在Condition成立的情况下执行Process，由此产生一些新的Object或者改变Object的Status。

这样，无论是现实世界里的Object还是信息系统中的Object，他们具有对等的身份。

基于这一点，我隐约感觉到这里可以搞事情。

基于OO的思路设计出来的信息系统只会是被动的工具。如果把信息系统仅仅理解为现实世界的映射，那么在设计系统的时候，更多的可能是基于现实世界的需要为基础去进行信息系统的设计和建设。这样设计出来的信息系统里面的Object都只是被动的去处理信息的工具。

基于OO的思路设计出来的信息系统会丧失很大的灵活性。

1. 一笔订单干到底的启示？
2. 我们在设计信息系统的时候，会被信息的具体存储方式所限制。例如：一笔订单需要有一个表记录订单对应的数据记录，会有一个订单明细表记录订单的详细数据。
3. 重复购买的任务的启示。如果我们希望能够每个月购买一次大米。那么，很可能我们设计的角度就是，创建一个每个月购买一次大米的任务，然后由任务驱动创建订单。

但，如果基于OPM的思维会设计出一个什么样的系统呢？

1. 我们会创建一个订单的Object。
2. 订单这个Object的生命周期仅完成订单创建时所赋予的使命。
3. 订单这个Object为了完成在自己创建时的使命，它会使用更灵活的信息存储方式。而这些信息存储方式的目的仅仅是为了完成自己的使命。并不把重点放在，我要存储一个订单和一个订单明细。
4. 订单这个Object只在自己的使命范围内工作，并不会走到整个业务链条中审核、出库、运输环节。订单Object只是和他们发生了一些关系。
5. 在订单被审核通过，并不是订单本身的状态发生变化。而是订单获得了进入下一步的许可。它可以到下一步继续完成自己在被创建时所赋予的使命。而进入下一步的许可，是由审核对应的Object去管理的。
6. 如果是每个月重复购买大米的行为，任务的创建并不是由信息系统这个更大范围的系统去驱动的。而仅仅是有订单Object拥有了每个月订购一次大米的使命，自己去调用任务这个工具创建的。

那么，这样一来，订单Object便拥有了自己明确的边界并且自我进化的能够得到更好的释放：

1. 订单Object不会进入到其他Object的工作领域。订单Object仅仅为了完成自己的使命，触发其他Object去配合自己的工作。他们之间是极度松耦合的。
2. 订单Object不仅仅能够具备驱动其他Object的能力、使用任务工具创建任务的能力，而且当我们需要更智能的订单Object的时候，可以更灵活的升级订单Object的主体。这个订单Object的主体，会繁殖出更智能的订单Object。
3. 订单Object和它生存的信息系统之间的关系会更加的独立。因为它所生存的信息系统仅仅是为订单Object提供必要的系统资源、生活和工作的平台。信息系统并不关注订单Object究竟会在它这个平台上做什么，怎么做，信息系统不会为了订单Object去创建任务，而是提供任务创建的平台，由订单Object自己去为了完成自己的使命去创建它想要的任务。
4. 订单Object的主体具备可移植性。只要另外一个信息系统的平台具有订单Object的生存空间，订单Object主体就可以移植过去。并在另一个信息系统中生存。
5. 而，对信息系统的定义就完完全全发生了变化。信息系统需要形成一套标准的适合各类Object主体生存的环境（接口标准）：例如：主动创建存储空间、表结构、发送消息、创建任务、协同其他第三方服务平台等等能力。