场景如下：
- 有一些有图形交互界面的行业程序，用户给它提供输入，最终这个软件会产生一个私有格式的文字式的文件，经常带些朴素的表格之类的，以供在相关的场合里使用
- 这个行业呢，有几个大一点的玩家，和一堆小一点的玩家。各家都是传统的玩家心态，想守住自己的一亩地三分田。尽管在同样的行业里，大家多多少少用些不同的用词，流程，规范... 尽管说的都是同一回事。反映在软件里，就是对于同样的信息，产生完全不兼容的文件。各个玩家之间，也故意的相互不交流。甚至于，有时玩家给出文件的时候，是打印成PDF 格式的，而且这个PDF 的内部是混淆过的。
- 在平常使用时，用户需要打开一个桌面程序，输入密码，进入界面，手工敲入文字，选取选择框...等，这个程序的界面是会随着用户的交互而有所变化的，比如，选一个选项A，程序会显示一组后续选项，但如果选了选项B，程序就会显示另外一组后续选项。抽象的描述来说，这个界面是动态的；但是是可重现，可预测的。
- 有些用户呢，有时候需要和多个行业玩家交互，这时候，用户就需要把一个玩家发来的东西，手工提交到另一个玩家的系统里，在和第二个玩家交互之后，有可能还需要把新的内容再提交回给第一个玩家。抽象的来说，对于一个语意信息，用户需要费心费力的挪来挪去，和转变它的表达方式。
. 现在，行业扰动者来了。想在用户端，打通所有行业玩家间的壁垒。也就是说，玩家A发来的一个文件，内容是“选项A，选项B，文字C…”，在保持语意的条件下，转换成玩家B的“选项B‘，文字C’，选项A‘...”。因为时间就是金钱嘛，用户们会为这种服务付费。如果一次转换咱们收个一百万人币，一天一千次转换，那就完成了一个亿的小目标了。
. 这个壁垒连通器呢，想把它放在一个服务器端，对用户按使用量计费。给我一个玩家A形式的文件，我返回一个玩家B形式的文件。
. 抽象上来说，只要定义一套完备的转换规则，这个软件就成了。哪怕咱们用上最菜的码龙，最乱糟糟的测试，无设计的群豺式的敏捷开发战术，997的工作时间... 也能在几个月内砸出一个粗糙的钻石。
. 现在呢，设计的焦点就是，如何在服务器端，完成这个转换？成本什么的现在就先不考虑了，咱们只要一个可行的方案。
--
FROM 47.144.174.*