我正在参加「掘金·启航计划」
前文提出数据转换是正确的方向，也提出了用数据转换的视角去理解程序，以及用数据转换的视角去从业务需求阶段去拆解、设计程序。接下来讲下实际的操作方法及步骤，来解除大家不知如何开始的疑惑。
现在，有一个业务需求和流程图，按照老规矩，你自己先用以前的思路大概架构设计下，回顾下思考方式、流程，点到即止，接下来完全听我说，中间不要走神儿。
业务需求的拆解
深呼吸——
第一步，面对业务需求和流程图，我们需要做的很简单。把用到的数据结构写出来。完全不需要思考任何逻辑部分，只写数据结构就完事儿了，别犹豫，放心大胆地写就行。
第二步，我们一直讲数据转换、数据转换，所以，肯定就会有把数据 A 转换到数据 B 的客观事实。这就是说我们要搞清楚数据的流向。怎么搞清楚呢？看着哈，前面已经把数据结构都定义出来了，那么我们再次看一眼流程图，同样的，不必分析逻辑，只看流程分支节点，把条件和导向的结果找出来就行。
不知道咋找？条件都晓得吧，不就是某个字段的状态么，结果就是受这个条件影响所产生的另外某个字段的状态变更。（当然了，这里说的字段可能是多个）
所以，现在我们就能把条件和结果关联起来了，数据的流向就搞清楚了。
至此，业务需求的拆解就完成了，我们毫不费力地完成了。并且，我们也顺便得到了完整的数据结构，以及明确的数据流向。干得漂亮！
数据关联与打通
既然有了数据结构和数据流向，那么接下来自然要根据数据流向把数据结构的流入和流出字段进行关联打通。这样就实现了我们的目标：数据转换。这样我们的程序也就算写完交付了。
老实讲，关联这部分的实现，是有实实际际的难度的。因为我们要真正开始写业务逻辑了，要把数据流向落地打通了。
不可否认的，我们利用数据转换的思想，对业务需求进行了拆解，非常容易。但是对于关联，至少在现阶段，在现有的编程语言、工具、方法上，还没有可以利用数据转换思想来实现的可行方案。
为什么呢？因为，在现有的编程语言体系下，我们要想把数据进行关联，就得控制、驱动数据，怎么怎么走，去哪儿去哪儿。丢进一个函数，然后继续再丢进下一个函数……这样就失去了两个数据的关联性了。
你可以简单回顾下自己写过的代码，是不是经常会遇到这种情况，两个数据间隔很遥远，或者属于两个不同的模块，在代码空间上就很难打通，要么通过函数层层传递，要么就得使用回调、事件、或消息的方式来进行关联。很别扭，也失去了关联性。这就没有办法好好地利用数据转换的思想了！
所以，常规来讲，现阶段还是要忍受别扭，多费点脑细胞通过架构、设计模式等等来进行数据打通。关联性只能忍痛丢掉了，这也是实在没有办法的事儿。
绝望后的希望
但是，我们是多么地渴望能够利用数据转换的思想，在关联上大展拳脚啊！那肯定会是简单又清晰的，令人向往，令人着迷。
千万别走开，常规之外，我们还真有办法，等着瞧……
告诉小伙伴们吧！
未完，请待下篇（绝望后的希望）
