软件发展史，不只是一部能力增强史，也是一部位置前移史。最初，软件贴着机器、介质和作业流程存在；后来，它逐步脱离这些直接约束，前移到更稳定的表达位置；再往后，软件不只负责执行，也越来越负责定义、组织和装配。沿着这条线回看，从孔带、孔卡与批处理，到高级语言和操作系统，再到数据库、框架、规则引擎、模型驱动、低代码与 Software-Defined X，许多关键变化都不只是“做得更多”或“跑得更快”，而是软件与其所依附对象之间的边界，被一轮轮重新画过。 把这些阶段放到一起看，每一步其实都在做同一件事：把某类原本绑在具体载体、具体实现或具体个体身上的差异，提到前面来表达，再把承接压到更下层去完成。
一、起点很低：软件还缠在机器和作业里 若把时间往前推，较合适的起点不是高级语言，而是孔带、孔卡和批处理所代表的早期计算时期。那时，程序和数据常常先被打到外部介质上，再交给操作员送入机器；机器按批次运行，过一段时间之后，用户再去领取输出结果。表达要求的方式、作业进入机器的方式、机器处理作业的方式、结果返回人的方式，基本还连在一起。 放在这一起点上看，最初的软件并不是建在清楚分层之上的。程序、数据、输入介质、作业流程和机器运行方式彼此贴得很近，还谈不上后来那种稳定的层间分工。软件更像围绕特定机器与特定作业方式形成的一整套操作安排，而不是建立在统一承接面上的独立结构。 二、第一步前移：程序先从机器侧退出来 高级语言出现后，变化首先发生在程序的书写方式上。人终于可以先用较高层的形式写出要计算什么，再由编译系统把这种表达转换为机器可执行形式。操作系统进一步把这种变化稳定下来。文件系统、统一 I/O、进程和命令解释逐渐形成较稳定的运行环境。 到这一步，程序不再总要直接面对设备差异、资源调度和作业控制，而是在一个相对稳定的承接面上工作。软件因此第一次较明显地从机器侧退出来：上面写程序，下面供运行；上面更多表达“要做什么”，下面更多负责“怎样稳定地把它跑起来”。 三、再进一步：逻辑表达开始独立出来 如果说高级语言和操作系统完成的，主要还是把机器侧负担压到更下层，那么数据库把这件事推进到了另一层。这里真正重要的，不只是“有了数据库”，而是对象、关系、约束和查询开始形成一层较独立的逻辑表达，而存储组织、访问路径、索引、并发控制、恢复这些，则更多留在数据库系统内部。 这意味着，软件开始不只把执行细节压下去，也把逻辑表达本身从物理处理方式中拉了出来。前面几步，主要还是机器侧复杂性的下沉；到这里，逻辑表达本身开始独立出来，前移这条线才第一次真正变硬。 四、继续前推：把实现里的差异提到前面 数据库之后，软件并没有停在“逻辑表达已经独立出来”这一点上，而是继续往前走。应用框架和开源基础框架，把大量原本散落在具体系统里的共性工作继续收拢到下层；规则引擎和决策模型，把原本经常埋在程序内部的判断条件和裁决逻辑提了出来；模型驱动与低代码，则进一步把系统描述、应用构成件、数据连接、表单视图、流程组织等内容，提到更前的位置。 它们表面上分别处理共性代码、业务规则、系统描述和应用装配，实质上都在做同一件事：把原先埋在实现内部的差异，提到更前面来表达。 五、范式先在资源侧成立：软件先定义基础设施 如果把前面这条历史线再往近处推，Software-Defined X 可以看作一个很有代表性的阶段。它的意义，不只是多了几个新名词，而是软件在基础设施层真正站到了更前的位置。原来分散附着在具体设备和硬件之上的配置、控制、分配和调度，被提到了一个更统一的软件层来处理。网络、存储、算力和资源，开始能够先在软件层被定义，再由更下层的机制去承接。 六、继续逼近：软件开始站到业务结构前面 Software-Defined X 在基础设施层站稳之后，软件的前移并没有停在资源一侧。接下来的变化，是软件开始越来越多地站到更靠近业务表达的位置。它前移所面对的，不再主要是网络、存储、算力和资源，而是越来越多接近业务表达的结构。 但到了这里，软件还没有直接变成“业务整体”的定义面。它先站到前面的，是那些较容易被显式表达、较容易被共同理解、也较容易被重复承接的部分。流程可以先画出来，规则可以先列出来，决策可以先说明白，应用构成可以先组织起来；而更大范围的业务运行，并没有因此一下子被整体吞进去。软件逼近业务，不等于业务整体已经变成可定义对象；它先吸纳进去的，只是业务中那些可显式表达、可重复执行、可公共承接的部分。这就是软件前移到业务附近之后首先遇到的边界。 七、门槛变了：从实现问题转向描述问题 一旦走到这里，问题的重心就变了。前面的阶段里，软件不断前移，主要是在把某些复杂性从下层抽走，再把某些差异提到前面来表达。可到了真实业务场景，下一道门槛往往已经不再主要是“能不能实现”，而是“哪些差异能不能先被公共地说清楚”。 换句话说，当软件已经能够承接一部分业务差异时，问题就从实现问题转成了描述问题。也正因为如此，BPMN、规则引擎、模型驱动、低代码这些东西之所以重要，不只是因为它们提升了实现效率，更因为它们都在逼问同一个前提：业务中某些差异，是否已经稳到可以先被明确表达出来。 也正是在这里，“业务与技术的解耦”这个话题才真正成立。这里说的解耦，不是业务脱离技术，也不是技术脱离业务。业务离不开技术承接，技术也不可能脱离业务场景独自成立。所谓解耦，指的是：业务中那些已经可以被系统承接的差异，其描述不再必须依赖任意特定技术个体的私人翻译。对象如何界定，状态如何迁移，规则如何裁决，流程如何展开，这些事情不必再先进入某几个技术人员的私人理解，业务才有机会进入数字空间。这里真正变化的，不是谁离开谁，而是描述能否从私人翻译转成公共表达。 然而，行业长期默认的起点，其实一直是“需求—翻译—实现”，而不是“描述—承接”。业务侧往往知道自己要什么，却很少拥有一种稳定、公共、可校验的表达方式；技术侧则通过整理、取舍、补全和重构这些材料，实际掌握了将业务意图定形为系统结构的权力。只要这种“私人翻译”的结构不变，解耦就无从谈起。主流企业软件又更习惯按部门、职能、模块和流程段来切系统，而不是先围绕那些需要连续承接的业务对象来组织表达，于是系统承接的是片段，片段之间如何接起来，却长期掌握在少数人手里。 八、判准：解耦是否成立，只看这一条 因此，软件一路前移，最终把问题推到了这里：解耦是否成立，不看技术是否参与，而看业务中那些已可被系统承接的差异，其描述能否脱离特定技术个体的私人翻译，转为前置、公共、可校验的表达。技术随后承担承接、运行、校验与边界保障。 若这一步做不到，技术就仍实质占有定形权，解耦便未发生。到这里，业务与技术的解耦才不再是口号，而成为可验证的结构命题。
夜雨聆风