在过去的开发过程中，我发现所谓的业务，在企业级应用的背景下，最终的实现操作都是数据库的增删改查，或者说通俗点说都是数据库的操作，其他的业务类型多多少少是在围绕数据库的操作。在用户的需求最终转化成设计再到代码的实现。
我这里说的业务可能是一个有别于技术的东西，有些东西纯粹是靠技术来实现的，用户没有概念，跟他说也没有用，比如做接口，你可能用web service 。用TCP通信等等。这些很多是用户是看不见的。
我认为一个比较理想的业务系统应该是业务驾临在技术之上，二者相得益彰。技术需要解决的问题是他有一个平台，能让业务方便的在这个平台上实现。所以我们在做架构的时候要分清楚哪些是业务需要解决的问题，哪些是技术需要解决的问题。
从业务的角度看技术，我希望业务能够非常方便的在这个平台上实现，不仅如此，我还希望我的业务变更了。能够以最少的改动或者不改动就能够实现变更。理想的做法我希望业务都是配置进去的，我在变更的时候只需要修改相应的配置就可以了。当然100%的配置出来也不太现实，据我所知，在sap,siebel里面的报表是必须开发的。因为报表主要是查询，查询就非常灵活，单靠配置能难达到目的。
从技术的角度去看业务，再好的技术加上一个不入流的设计，都为成为教科书上一个很好的反面教材。业务人员需要在对业务的把握上设计软件。
既然要复用，要能够用配置实现业务，那配置些什么东西了?那些地方可以配置。这个就是框架要做的事情了。说到框架大家最喜欢议论的就是怎么快速实现crud了。毕竟，一个系统的很大部分都是在做这个事情。