程序中的各种类(class),包(package)等首先体现的是架构设计中的一种概念分布. 一个良好的设计相当于是建立一个结构合理的概念框架, 随着系统的不断发展, 作为概念载体的类(class)不断吸收相关的实现, 从而使其外延不断丰富起来, 而其内涵也愈加变得明晰. 系统中概念的分化, 最显著的不是业务模块的划分, 而是技术层面与业务层面的分离. 因为技术手段与业务在很大程度上是相互独立的, 因为 [无论]实现什么样的业务, 我们[都]将用到某种技术手段.  而当我们可以回答一个"无论..都" 的问题的时候, 它意味着某个概念可以容纳众多变化, 而它自然有资格成为某种独立的部分. 

  作为技术层面概念聚集的例子, 我们可以看一下spring framework中的jdbctemplate类, 这个类在spring的概念体系中对应于"jdbc调用帮助类"这一概念, 它的目的是帮助我们尽量通过一次函数调用得到我们所要的结果, 但是我已经不止一次的看到很多人使用如下调用

   list results = jdbctemplate.query(...);
   list ret = new arraylist();
   for(int i=0;i<results.size();i++){
     ret.add(((map)results.get(i)).get("somefield"));
   }

   这段代码的目的是为了得到某一列的值, 而jdbctemplate类没有直接提供这一函数. 为了不等待spring的升级, 显然我们需要建立一个jdbctemplate的扩展类, 它直接提供一个queryscalarlist函数, 而不是让这种纯粹技术性的循环语句散见在程序代码的各个角落.

   告别裸奔编程是我对同事的基本要求之一. 即使是考虑最细致的软件组件, 它也难以保证能够预想到所有的变化形式, 而在系统中集成一些第三方组件的时候, 一般总要加入一些特定的假设, 此时也需要一个技术隔离层. 例如在页面开发中, 我们强制使用witrix平台定义的js.ajax对象, 而不是prototype.js中原始提供的ajax.updater等对象. 在应用一段时间之后, js.ajax对象上聚集了一系列与ajax相关的调用指令.