我们知道，为了应对可能的变化和功能解耦，我们有许多编程技巧，典型的如设计模型、IOC和AOP等方法，但这些技巧在目前的系统架构基本都是应用在程序级。但由于SaaS模式需要数据存储和应用服务采用分布式架构以达到SaaS云计算的要求。这就需要我们将这些传统的技法提升到业务层面进行考虑。当然，对于程序级内如果需要这些技法解决程序级领域内的问题，采用肯定没问题。但由于SaaS业务的特殊性，对于我们原来的应用架构所考虑的问题都应该放在更高的维度进行考虑，这个时候，将这些技法应用到整个平台业务架构上，同样可以解决和应对业务变化和解耦的需要。
比如，AOP，在SaaS层面上，我们可以利用数据库或者消息队列（MQ）设计整个SaaS应用的切面点，正如在程序级，我基本不住张AOP而言，在SaaS业务层面，同样主张要慎用。因为在SaaS业务层面使用AOP技法对产品和架构的要求就非常高，特别是产品，因为在传统的产品模式下，产品一般不会对架构和技术投入过多的关注，而在SaaS业务层面引入这些技法，反而对技术本身的要求降低了，但产品和架构需要联合设计和平衡这种产品业务设计模式做布局和平衡，需要考虑业务产品的扩展性、复杂性、可部署、可维护和易实现性。AOP书籍中引用得最多的日志切面，其实在业务层面可以做更多的东西，弄出更多的花样，比如增加分析，报警，通知等。
比如观察者模式，在产品业务层面使用其实更为有效，比如某个数据主题的订阅，由于脱离了程序级的束缚，订阅者本身处理更加解耦，对于主题的计算影响很小，所以功能的叠加上就更加灵活。
再比如利用组合模式对业务单据进行通用化和个性化的平衡，将模板方法应用到业务初始化，使用指导和检核。严格来讲，程序级上的这些设计模式都可以再业务层面上进行使用。但这种使用的控制需要在产品设计上进行，因此对于产品设计的要求就非常高。而传统的系统架构师要做这块，也必须能用方法补齐业务短板。所以，我一般都建议在SaaS产品的开发中产品需要和系统架构师紧密配合，产品需要有这种意识，而系统架构师也需要有架构匹配业务的胸襟。
设计模式，方法永远是抽象的，从来就不应该被局限在某个领域或者层面，作为产品或者架构师，都应该充分利用这些知识的结晶。目的就是做出符合需求的产品。这其实也是对IT从业者一种基本的意识要求。
补记：现有的Java主流架构也好，还是DotNet的主流框架也好，实际上对于SaaS开发都不是特别友好，需要大家做出一定的突破，而不是循规蹈矩的陷入到这些开源框架本身预设的一些场景下。特别是Java中大量的IOC使用。
在SaaS化层面，你的舞台就不在是单个的应用程序，不再是一台或者几台电脑，而是整个世界！
