数据大体上可以分为 接口类数据 和非接口类数据。前者意味着契约，后者关于实现，后边提及数据，一般指后一种。数据还可以从 生命周期，聚合根，等角度分析。
基础行为(basic behavior，bbhv)
数据拆分还有一个角度业务的角度。抽象数据，即从算法(或业务逻辑)角度描述应该存在的一个东西，缺了它，很多行为就毛将焉附了，它聚合了一簇相关的行为。OO方法看，这抽象数据应该封一个类。
数据类只get/set就贫血；涉及太复杂流程，弄个数据团又成了上帝类，这个权衡把握实际上很难给个一刀切的标准。实际上某个特定系统在设计之初，就应该给出适合它的框架结构帮助达成基本一致的拆分，这种结构可以另文讨论。
从行为分类的角度看，这些行为是基础行为(basic behavior，bbhv)。bbhv，是编程的基本单位(基本单位绝不是单条语句，单条语句什么也不是！)，它描述的是在一个特定场景下处理某个原子操作的实现，它直接访问某个抽象数据的实现。不涉及多个数据间的协作，也不涉及不同场景下的择路。bbhv的实现中，一般不会用到if/else。
具体行为(concrete behavior，cbhv)
有了大量的bbhv，需要把它们组合在一起，完成业务逻辑的描述。这种描述流程组合的行为，可以称作框架或过程。我喜欢称之为具体行为，cbhv，而框架(frame)则专指组件/模块最顶层的过程。cbhv负责完成系统的组合，只描述分解的步骤，也就意味着它有不同的层次；cbhv不涉及具体的数据，只引用聚合根的ID，这样即便在c语言中也可以比较容易的实现灵活的组合。
cbhv中对组合的控制元素，可以包括loop 和 break 机制(如因失败或超时的退出)，但不应该包括择路。不包括择路的理由是：
其一，如果允许cbhv择路组合过程的复杂度立刻会激增以致难以控制；
其二，cbhv中希望体现的组合的过程就会被湮没在大量的择路中；
其三，择路是应该被独立设计的变化方向。
这样，就需要一种特殊的行为来描述选择了。留意看的话，在bbhv的描述中实际上也欠缺关于选择的实现。
抽象行为(abstract behavior，abhv)
一个行为，完成某个逻辑功能，但在不同的场景下有不同的实现。这个行为就是抽象行为。抽象行为在软件分层结构中，描述的是高层定义的函数(行为)接口。抽象行为的选择器(选择哪个实现)，是 状态/场景/开关 这一类特殊的数据决定的。这种数据也是拆分其它数据的理由。选择的变化周期，和引用它的cbhv并不相同。从业务逻辑看cbhv/bbhv的变化方向和abhv并不相同，前者随业务流程或具体数据实现形式变化，后者只随状态变化。
abhv的具体实现可以是多个bbhv，也可以是多个cbhv，或者两者的混合。选择器从中择一。从逻辑上不排斥它的实现也可以是abhv，但这情况下要给出为何不将它们合并成一个abhv的充分理理由。由于选择条件使用应该具有一致性，所以这种理由其实不好找。
实现组合编程
abhv的设计也是管理系统复杂度的关键所在，它没有b/c那么直观，实际上这三种行为都需要细致的拆分和抽象。
这三种行为各司其职：
bbhv负责实现，生产基础部件；
cbhv负责组合，把零件拼装起来；
abhv负责选择，指导选择合适的零件实现一致的功能。
最终实现组合式编程的目的。巧的很，行为的名字叫 a/b/c behavior，所以本文也可以叫 《行为ABC》。
