IT行业发达的今天，各种软件架构百花齐放。其中异步架构异步架构凭借高并发处理能力成为分布式系统的核心选择，RESTful 统一接口架构以其通用性简化了跨平台交互，微服务、云原生等架构更是推动着系统向更灵活、可扩展的方向演进。

但回到1966年，软件的开发者们则会简单地把业务逻辑写进数据库。比如，数据库的前身，IBM在1966年发布的IMS（信息管理系统，Information Management System）的一项核心功能就是让用户可以直接在数据库里存储和执行业务层的逻辑。这个做法的一大优点就是能够显著提业务逻辑的执行效率，因为数据和业务逻辑都集中在了数据库层，减少了数据的传输成本。这在那个没有光纤甚至宽带的时代解决了数据传输的一大问题。

把业务逻辑写进数据库的另一大价值在于数据的安全性。程序员把业务逻辑放入作为数据源头的数据库，则可以有效控制数据的读写权限，从而让外界可以接触到的数据保持在最低程度，从根源上降低了数据泄露、篡改的风险，为业务数据提供了坚实保障。

这种看似 “古老” 的架构曾经被NASA采用，并用于给阿波罗计划管理材料库存。但它的速度，稳定性和安全性很快得到了银行业的青睐。随后，电信业、制造业、零售业等行业也纷纷跟进，将其应用于账单管理、生产流程管控、库存统计等关键业务场景，成为那个时代的 “主流架构”。

从简单软件的开发与使用场景来看，“方便省事” 更是不容忽视的核心诉求。但业务逻辑写进数据库这种“中心化”的行为在迈入互联网时代的今天并不受欢迎。它就像是大数据，分布式集群，微服务等互联网名词的反义词。事实上，绝大部分软件并非互联网平台型产品，它们既没有百万级 DAU （每日活跃人数）的压力，也无需应对高并发、跨地域的复杂需求。

软件架构无优劣，只看场景适配度。1966 年 “逻辑嵌数据库” 模式，以高效，安全，便捷适配了早期需求；如今的分布式，微服务虽然流行，但多数软件无需高并发。这种“古老” 架构仍能以低成本解决核心问题，架构选择的本质是贴合业务需求。