一个可能的场景——订单审批：
[用户]我进入界面
【系统】系统过滤出页面控制，只能看到审批订单的界面。
[用户]查询订单
【系统】系统自动根据我的状态，过滤出我能够看的订单(workflow)
[用户]我进入订单明细，填写确认数量、备注等信息，确认/拒绝
【系统】系统获得我的数据，然后
【系统】进行数据处理(dataflow)
【系统】修改订单状态(workflow)
【系统】用email通知顾客(email)
【系统】用企业内部Msn通知库存部门发货(msn)
【系统】页面自动关闭(pageflow)
【系统】自动转向开始的列表位置。(pageflow)
用户部分是不可能提出框架的，主要就是页面设计部分、用户操作的数据对象部分。例如我用A布局查看到货单、B布局查看订单，这个是不能形成框架，因为非常没有必要，多变反而增加了编程的难度。
剩下的系统部分，每个子功能可以形成框架，但是总和似乎不能形成框架，还是要根据用户需求调用。比如单据系统处理完了，插入数据库了，那么是否需要email通知顾客呢？这个不能够用框架完成，也是多变的，今天email，明天就qq。
但是微软的WF似乎希望进行统一，他每个activity的执行部分用户能够自定义，这样就能够不断添加新的需求。（是个很有趣的思路）
讨论——到底有多少能够成为框架？
dataflow，数据流，已经成为框架了，我用samsara完成，用户只要写脚本就能够完成各种后台数据库操作。
workflow，工作流，已经存在很多的框架，我需要进一步了解他们到底有多强大，比如ofbiz, aspose, 涉及到bpel, WfMC, patrol网等。
pageflow, 页面流，目前好像没有单独的，BEA有个基于页面流的编程框架beehive，但是实在不好用。
框架之后呢？
框架之后，要么是简单的应用，比如个人网站、小程序、淘宝之类的大众商务网站。这些没有形成理论体系。
框架之后，复杂的应用，CRM,SCM,MIS,ERP...这些形成了理论，因为和企业利益紧密挂钩。
框架之外，开始涉及数据挖掘、推荐系统、搜索引擎、语法分析、等等带有智能的系统，他们成为一个模块，辅助。（走远了）