数据续谈

RDB 的底层是 Records 和 Relations，在应用层则发展出了 SQL，代表一种比 OO 更简单的范式：

声明式描述，把 Rule/规则/逻辑组合以数据描述的方式展现出来，来代替 OO 繁杂的逻辑描述；

这种范式是 DSL，一种动态加载逻辑的方式，本质上是一种插件的实现方式。

但也有其缺点，不同 DSL 间无法兼容，有学习成本，难以复用，属 one piece of code；

优点也很明显，入门简单，可以没有编程基础，但深入时坑也多。

本着对复杂敬畏的态度，一般不自己轻易实现 DSL，但如果核心域的扩展/插件很多，可以提供简单的 DSL 以实现简单的需求，比如 CRUD；

不过由于 DSL 约束规范实在太少，以及全手写 SDL 也容易引人认为失误，对这些简单的 DSL 也封装了可编程接口 ORM，对此有如下几种理解：

1、ORM 在 SQL 基础上提供了 OO 抽象；

2、ORM 和 SQL 都是 RDB 提供的应用层接口；

3、SQL 时 RDB 和 ORM 之间的共同抽象依赖，解耦了 2 者。

从经典学习，因为其解决了当时的主要问题而成为经典；

所以学习经典不是直接拿来解决当前的问题，而是提供我们学习的素材，进而让我们练习分析问题、解决问题的能力；

熟读经典，让自己有压箱底的武器库。

举个例子，构建一个列表：

<lt>   <li/>  <li/>  <li/></lt>

这是手写代码实现，最容易，但不是最简单，当业务逻辑增加时，复杂性可能超线性增长；

以上也可以说是过程式/命令式思维范式。

另一种是：

data=[  {lable: a, value: va},  {lable: b, value: vb},  {lable: c, value: vc},];  //数据面
<lt data={data} /> //控制面

这就做了控制面和数据面的分离，也是当下最火的微服务的核心思想之一，暗合 DSL 范式；

其中控制面就是 RDB 的引擎，数据面就是业务通过 DSL 的直观表达；

也是软件演化所追求的方向--让业务逻辑能使用数据布局的方式来直观表达，这种方式比 OO 更简单，或者说这本不属于 OO 该做的事，OO 做的是控制面的事，数据面的事，还是有数据布局来做，DSL 是一种复杂的数据布局方式，但简单的结构体、json 更为常用。

回到集合

集合做为高级数据结构，用来描述更复杂的数据布局;

集合与逻辑之间的共同抽象依赖是迭代器，这让逻辑表达解耦了数据布局，摆脱了 RDB 强依赖导致的不能复用问题;

迭代器的各种操作函数 map，filter，reduce，就是数据处理 pipeline 抽象出来的 DSL，让工作流逻辑的表达相对直观。

消除重复做为代码设计最底层的驱动力，

逻辑有重复规律时，就提取数据组织新的布局，保存在集合中，让逻辑稳定下来;

数据有重复规律时，就用组织逻辑来自动生成数据，输出到集合。

逻辑和数据的表达，还有一种方式：IDL。

好处是简单，所以为一种语言实现也容易；

软件开发首要的是划分边界，IDL 就是划分边界的一种最佳实践。

后端服务间 rpc 一般都用 IDL 来定义协议，能快速把系统框架搭建出来。

一般的实现是序列化库+rpc，如 grpc，grpc-web 支持了浏览器端。

IDL 的难点，不在技术，在业务的需求分析，边界划分，数据建模。

大家使用 pbuf 时遇到的问题，也欢迎分享。

IDL 也会随着需求增加而逐渐变得复杂，如重复项需要提取出来；

还有就是接口依赖问题，导致需要请求多次；

最后是接口的版本管理；

GraphQL 针对这些问题做了改善，算增强版的 IDL。