canonical_cqh的专栏

对象本质上是一种命名技术，即将一组相关的数据和函数放在一起，起一个名字。从业务层面上看，我们需要识别出大量的概念，对应到建立的领域模型，我们就拥有不同的业务对象。这些业务对象的类型各不相同，可以区分出来。从中间件层面上看，需要从大量业务对象中抽象出共性，并以统一的方式进行处理。即在中间件层，所有业务对象的类型被弱化下来，实际上丧失了其各自的独特性，即在中间件层看来，这些不同业务对象的类型是相同的。

cocoon的文档中有这样一段话：Traditional Web applications try to model the control flow of a Web application by modeling the application as a finite state machine (FSM). In this model, the Web application is comp

    理论物理的优美在于从少量基本原理（如最小作用量原理）出发推导出整个理论大厦。而在软件设计领域却充斥着林林总总的"最佳实践". 太多的规则只会意味着没有规则。软件设计领域的现状说明这个领域还处于非常稚嫩的阶段，应该从其他领域借鉴更多的知识。在我前面的blog中已经说明了在软件中的一些具体的分析技术。但如何有效的应用这些分析技术，我们还需要一些指导性的理论框架。如果把软件设计放在更加广泛的系统

控制论的基本哲学是：对于一个未知的黑箱系统，仍然可以根据观察建立控制模型，简言之，即控制有理。无论是物理系统，生物系统，社会系统，其控制的机理是一致的。这里所强调的是一种广义的建模，即我们并不寻求该系统本质上的物理模型，而是寻求一种"有用"的模型。实际上，在数学上早已准备好了多种广义模型系列，最典型的Taylor展开可以建立不同级次的多项式模型，我们所要做的只是根据不同的需要去做拟合。

关系数据库的关键之处在于关系的分解，在数据库中只定义了数据之间的两两关系，与应用相关的更复杂的数据关系需要在运行时通过动态join来构造出来，即这些关系储存在程序中而不是数据库中。实际上，关系数据库的一个隐含的假定是数据之间很少关联，而在实际应用中单表和主从表也正是最常出现的情况。当一个应用频繁需要大量表的连接操作的时候，往往意味着关系数据模型的失效，此时我们将不得不放弃数据的无冗余性，需要通过预

 Unix中的Pipe模型被认为是Unix最美妙的思想之一: 大量独立的小工具通过管道组合在一起，可以构成非常复杂和多样化的功能。例如:dir|sort。 这是一种功能正交分解的做法，其隐含的一个基本假定是这些小工具之间具有完全的对称性，即Pipe模型本身没有限制哪些工具可以组合在一起，也没有限制这些工具组合时的顺序。当系统逐渐复杂起来，对称性发生破缺(Symmetry Broken)，则出现了L

建立级列(Hierarchical)理论，首先需要建立最广泛的模型。在量子力学中，确立了如下基本概念： 1. 确定性的态。 2. 所有态构成完备的态空间。 3. 系综(即态的集合)的动力学。   首先，状态的确定性非常重要。即使在量子力学中，量子态存在几率诠释，态函数本身在数学上仍然是确定性的，即在任一时刻，任一地点存在唯一的值。如果我们的讨论没有一个确定性的基础，那所有的推演都将变得极为困难（模

  分析学的离散形式是分而治之(Divide And Conquer)。 这一思想在软件设计领域的重要性不言而喻。 大系统分解为小系统，小系统分解为模块，模块分解为对象，对象分解为函数，函数分解为增删改查等动词和集合/个体等名词，如此递归下来。 在很多关于软件的"最佳实践"中，都列举了这种分解过程中的注意事项，如高内聚，低耦合等。 但是为什么要强调这些概念，谁能保证这个checklist是完整的，

最近几年关于模型的提法突然多了起来，但这个概念到底意味着什么呢。从哲学上说，我们的思想是外部世界结构在主观意识中的反映，当我们把主观意识再投射回外部世界时，就得到关于外部世界的模型。所以，在最广泛的意义上，模型不过是我们思维中的一组关联。问题不在于我们是否需要模型或者什么东西是模型而什么东西不是模型，我们所意识到的一切都是模型，无论它与真实情况的差距有多大。我们所能区分的只是什么是一个"好"的模型

    分布式有几个核心问题。首先不存在全局的状态空间，各个节点上的状态可能不统一，节点之间的通信需要通过序列化等方式跨越状态空间边界。一般只有只读数据才能做到真正的分布式，因为只有只读数据才能维持各个节点之间的一致性。第二，节点之间的信息传递都是单向的，不存在test_and_set这样的锁原语（test_and_set需要同时信息双向流)。如果需要建立分布式锁，必须存在中心协调者,即存在着瓶颈