关于系统性能的思考

对于如何设计一个扩展的业务对象模型，我目前也处于探索中，但是我敢肯定的就是设计对象模型是一定要划分出一个边界，然后设计为一个聚合，这样整个对象模型由不同的聚合来构成，并且访问聚合内部的对象都要通过聚合根来控制。这样提供一个全局的访问控制点，便于维护和管理。并且我们设计聚合的时候，一定要区分出根对象中哪些属性是经常变化的，哪些不是经常变化，这样我们可以把经常变化的属性独立出来，作为一个值对象。这样通过对对象的细粒度的设计，我们可以更容易控制我们的缓存。所以我觉得对象生命周期很重要，这就设计到了DDD中的工厂和仓库两个模式，我目前的设计中，我是通过工厂来控制对象生命周期的起始，并且保证对象创建出来的聚合根式满足系统不变量的约束的，那么对象创建以后，其它的生命周期交给仓库管理。仓库(repository)管理对象创建以后的生命周期，我觉得这个时候就要使用缓存来管理了，我们要想得到领域对象，只能从一个地方来获得，那就是仓库，而仓库首先通过一个全局的缓存中去获得对象，如果缓存中没有就从数据库或者其它持久性数据源得到对象，然后放到缓存中，这样系统中的所有对对象的访问，都需要经过统一的地方：仓库。当系统中发生了引起领域对象状态变化的操作以后，我们可以清空缓存中的对象或者只清空领域对象的一部分，比如分离出来的状态。

最后使用全局的缓冲还有一个好处，那就是集群环境下面，因为我们可以把全局缓冲通过一个分布式的缓冲透明的替换，这样减少了不同节点之间同步session，以及session failover的开销，这其实就有点SNA的味道了。呵呵。



不知道您有没有读过：<<领域驱动设计>>这本书，这本书我觉得非常好，如果没看过，推荐您看看。这里面详细简介了如何开发一个针对于自己当前业务状态的对象模型。

第一：池化系统的功能性组件
    在每个系统中，我想都会存在功能性的组件，比如当前开发当中的service，这些功能性的服务一般来说都是没有状态的，是可以多用户共享的，这种共享的服务对象，我们也需要将其进行统一的管理，幸运的是目前已经存在很多这样的管理功能性服务的框架或者容器，比如目前比较流行的各种IOC容器，或者是重量级的EJB容器，它们都提供了对系统中各种服务组件的管理。