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