我过去从不同的人那里听说过 Data Driven 和 Event Driven 模型这两个术语。我做了谷歌，但这些术语对我来说仍然模糊，因为两者
其中一些看起来和我很相似
数据驱动编程是一种编程模型，其中数据本身控制程序的流程（而不是程序逻辑），在 事件驱动编程的情况下， 控制程序流程的是事件而不是数据本身。
按我的理解事件也是数据。例如在基于员工的 Web 应用程序中 - 如果用户单击创建员工按钮，这里的事件是创建员工（这也是一种数据），数据是员工相关信息。
现在在服务器上，首先由事件决定程序的流程，然后数据（员工相关信息）也将控制执行流程，例如是否将执行永久员工不同的方法，如果是临时的，它将是不一样的
所以不是每件事都是数据驱动的架构吗？如果没有，它们之间有什么区别？任何基于网络的示例都会有所帮助
【问题讨论】：
标签： event-driven data-driven paradigms
数据本身控制程序的流程（而不是程序逻辑）
我猜你还没有完全理解在这种情况下什么是“流”。流程本身就是逻辑。例如，如果您正在执行某个方法，对它的参数执行 A、B、C，逻辑将是“应用 A、B、C”，如果提取动作 A、B、C 以分离，则流程将相同方法。所以，流程和逻辑是同义词。
数据驱动编程表示存在一些通用代码。它不包含任何业务逻辑，也不控制流程。它只是一个读取和处理数据并输出结果的工具。控制流程和逻辑的是数据本身。因此，如果您想更改业务逻辑（字面意思是更改程序的结果），您更改的是数据，而不是代码。
而且您的代码是，它是一种根据输入数据执行命令的管道。你可以把这样的代码想象成javascript中的eval函数。
在事件驱动编程中，逻辑是由事件控制的。这意味着数据只是数据，所有业务规则都放在代码中。事件会携带一些数据，并且可以根据事件的数据改变逻辑，但这里的区别在于这些变化的逻辑规则放置在哪里——数据或代码；在 EDP 的情况下，逻辑在代码中。
另外，请查看this 问题，一些答案可以对这个主题有所启发。
【讨论】：
上面的解释很贴切。作为对上述答案的补充，在数据驱动架构中，业务可以直接在数据表中输入逻辑，从而非常容易控制下游组件中的逻辑。喂食通常使用用户友好的工具来完成。通常维护一个产品主文件，该文件由数据变量组成，并且根据业务需求进行更新。与事件驱动相比，业务需求的每一个微小变化都会导致开发-测试-部署软件的巨大成本。
【讨论】：