现在本页面上看到的中间正文部分(表象)，是由三个部分(本原)组成的：
表象： 文章正文
本原：
           1 文章摘要：{中心思想等.....}
           2 段落列表：List<{段落正文等.....}>
           3 最后作者: {名号等.....}

1 xxController调用xxAppearance表象的构造方法，传入前台入参创建出xxAppearance表象。
2 Service对表象执行标准变换：
   2.1 根据表象中定义的本原数据集范围，查询相关数据集。
   2.2 根据表象中定义的表象与本原间的构成关系，构造出表象。
   2.3 根据表象中定义的表象变换与本原变换的关系，执行数据变换。
   2.4 根据表象中定义的表象与本原间的拆解关系，拆解出本原的映像集。
   2.5 把拆解好的本原映像集存库。
3 xxController拿到表象及存储结果，适配成前端响应数并返回。

 过程式的耗时： 每次数据交互时长的累加。
       认知式的耗时： 每个依赖交互批次的最大值累加。

过程式的业务逻辑与数据操作是串行的。认知设计里没有过程的概念，天然支持并行。但它无法逾越数据依赖(第二次查询的条件依赖于第一次查询的结果)。
在上面的例子中，本原集的定义有两批：qualifierGroup1st和qualifierGroup2nd。在2批次中完成了原来的3次查询，性能提升约1/3。
本项目最复杂的表象HierarchyAcceptAppearance在5批次中完成了30次数据交互，性能提升6倍。

过程式编程： 不透明依赖
      认知式编程： 透明依赖

 

过程式service类中的方法，可以在方法执行的过程中随意读写数据源，故而影响返回值的因素并不全在入参里，属于函数式编程中定义的不透明依赖。

     认知式只需描述表象与本原集间的3个关系，不直接操作数据源。而表象与本原集间的关系都是函数，都是透明依赖。

过程式没有办法从方法签名中读到返回值到底受哪些因素影响。可理解为依赖不可读，简称不可读。
      认知式业务方法的返回值都可以从入参确定受哪些因素影响。可理解为依赖可读，简称可读。