这套编程思想，从我日常工作中总结得来，用于解决一些复杂业务问题。内容偏抽象，表达能力有限，不喜请绕道。
一、调研客观数据，放弃主观思考。
以往解决问题，往往基于认知和思考。认知是有限的，主观思考易产生偏见。
解决问题，就从问题本身出发，尽可能搜集问题的表现数据，找出数据特征和规律。最后，程序要的做，就是把数据的特征和规律描述出来。
二、程序是数据的处理过程。
所有程序，最顶层的抽象，都是数据的“输入 – 处理 – 输出”。如下图所示：
实现中，中间的“处理”过程，是程序的主要复杂点。“计算机科学领域的任何问题都可以通过增加一个间接的中间层来解决”。对于复杂的处理，一个中间层不够，那就多个，于是可以得到：
在上面的模型中，每层都封装了数据。一层的数据，转换为下一层数据的过程，就是逻辑。
下面是一个虚构的商品请求程序模型：
这个商品请求程序模型，存在五层数据。第一层的数据是“商品请求数据”，通过逻辑“查询商品”，转换为第二层的数据“商品基础数据”……
程序也可以描述为：输入数据，经过多层转换处理，最终得到输出数据的过程。
三、数据模型和关联。
数据（模型/结构）由属性/字段组成，不带操作/逻辑（逻辑被视为数据的转换过程）。每层有一到多个/块数据。单层内的数据之前可能存在关联，这种关联在代码上表示为数据间的组合。
下面是一组虚拟的用户和钱包数据模型：
上面的数据模型，如果用代码来实现，可能是下面这样的：
type Wallet struct{
Currency string
Balance string
}
type User struct {
NickName string
Wallet *Wallet
Credit int
}四、完整的可实现的程序模型。
一个程序模型示例（省略了数据模型细节）：
在上面的示例模型中：存在多道程序逻辑（数据转换逻辑），模块间的边界清晰，部分数据和逻辑被复用，部分数据被复制而不是转换到下一层（实际代码中可能什么也没干）。
下面是一个虚拟的下单请求程序示例（只有一道程序逻辑）：
最后要做的，就是用代码，把这个程序模型描述出来。
下面是一个真实案例的模型（省略了大量细节）：
上面真实案例模型，是一个邮件发送程序，包含一个邮件发送的通用框架，这个框架支持不同业务（图中的1、2、3）的邮件。
