通用和专用是编程的永恒主题，编程的演化很大程度上是专用变通用的过程，归纳是更一般的叫法。专用与通用比较，往往具有更多的上下文约束，而程序设计则希望通过更细或更有效的分组、分类，而使这些上下文约束更通用，更具适应性。
对于企业应用来说，这样的约束一般来源于业务逻辑，而需求和程序设计也是围绕着业务逻辑的选择和处理展开。很多概念的形成有它自然的过程，如果经常把这些概念举在手上，反而如一座座山峰，遮住了事情本来的面目，这样也不利于这些概念的运用，当然拿来吓人或显摆的除外。
SQLDB关注于业务逻辑实体的结构及基本约束的一致性。NOSQL则揭示出业务逻辑实体的结构与业务逻辑对象的上下文相关性，也就是数据的结构与具体数据的相关性，完全通用的结构已经难于满足现在需求。BPEL则说明我们不单关注于数据的结构和模式，数据的来源、数据的有效性、业务逻辑对象的演变过程(即生命周期)，也纳入了编程的范围，更多地以动态的视角去观察、设计系统。业务逻辑的知识表示，则表示新的、平常化的信息化需求，对编程的效率、简单化、智能化提出更高的要求。
这是以前写的一篇随笔，因为有许多不同的想法，想加一个评注，只是写着写着就有些多了，于是整理一下就放在一起了。灰色字体的部分是原来写的，放在一起并不表示同意原来的观点，只是留作记录和对比。
流程是一个很热的词汇，试着总结一下，理得不算很清楚，但也不至于太糊涂。
流程的特点：
0、流程体现的是前因后果，不会出现种瓜得豆的情况。
1、流程是虚拟的，又是具体的，体现的是某一类事的运作规范，但又通过具体的事来体现。
2 、流程是调适的，会因外界的因素影响。
3、对于商业流程来说，流程体现的是商业模式的运作方式。
4、商业流程的起因一般是客户需求。
5、整体流程由多个主流程，以及许多与主流程相关的分支流程组成，流程间相互衔接。
6、知识和规范是控制流程的主要因素。
7、流程与组织结构相关，组织结构的执行机构一般根据流程来设置和分工。在设计流程时，组织结构通过虚拟的脚色来体现。
8、流程是资源运作的体现，流程也体现了资源变动的结果。
9、流程的权限是资源权限的体现，反映人力之间的职责分工。消息、通知、执行、控制可以认定为信息资源，权限可以通过资源的分配来实现。
10、流程强调的是执行过程的有效，而管理考核的往往是结果和形式。
11、流程反映的是过程性，而模块反映的是功能性，也可以这样说，流程反映的是线，模块反映的是点，各有所侧重。
12、有些流程侧重于管理需要，有些流程侧重于业务需要。
13、流程是有生命周期的，流程往往会跟项目管理结合。
14、流程可以通过消息和通知来交换数据。
数据的上下文:
业务实体的状态演变是软件系统运动的基本方式。 而演变的基本依据是业务逻辑，同时业务逻辑的实现应该基于业务实体的结构和内容，而尽量避免基于业务实体的存储结构。
从更细的层次看，业务实体对象的生命周期产生了业务实体的状态演变，业务实体对象生命周期的处理，是程序设计的核心。
模块设计主要关注实体对象生命周期的演变结果，而流程程序则关注生命周期演变过程。可以这样说，模块是流程处理的简化，主要关注数据的结果，而不是数据的上下文。流程与模块是处理同一事情的不同处理方式，过分强调流程的独立性，反而会限制流程的运用，这也许经常会把流程与审批挂钩的原因吧？流程应该是程序设计的基点，而模块设计只是流程设计的一种方式。
以往的设计，我们往往更关注实体的结构，毕竟程序是由数学演变而来的，结构是数学家的主菜，结构的能力是他们所关心的。而流程设计表示我们开始关注数据的上下文，关注业务对象的生命周期，关注业务数据产生的内在逻辑和相互约束，以及对目标的控制和反馈。
在上下文相关的设计中，临界集的求取(主要用于风险控制)、流程设计，应该是再基本也是易于程序设计。而业务逻辑的代码化实现，往往让程序缺少弹性和适应性，而好的设计要求有实用、有效的知识表达框架以及知识运用模式，以及多种语言的协同运用，现在实现起来还是比较有难度。从编程角度看，知识是词汇的演算，而我们还缺少这样的演算能力。
题外话：
读者对文章有自己的判读力，而书写者只要当时认为自己所写的东西，对别人有所益处或者值得与别人去讨论就可以了，随笔本身没有必要设置太多的前提条件。而要放置到首页，书写者本人是否应该有一道槛。