今天小编要和大家分享的是EDA,IC设计相关信息，接下来我将从事件驱动架构EDA的优缺点分析，第22讲____事件驱动ppt这几个方面来介绍。
EDA,IC设计相关技术文章事件驱动架构EDA的优缺点分析
通过事件进行应用程序的设计是自20世纪80年代后期以来的一种实践。我们可以在前端或后端的任何地方使用事件。当按下按钮时，某些数据发生更改或执行某个后端动作。
但是事件究竟是什么呢？我们什么时候应该用它呢？缺点是什么？
What/When/Why
当类或组件之间内聚性很高，它们的耦合度应该很低，也就是说当组件需要相互协作调用时，比如我们假设一个组件“A”需要触发组件“B”中的一些逻辑，自然的方式是直接让组件A调用组件B中的一个方法。但前提是A必须知道B的存在，这样它们之间就是耦合的，A必须依赖于B了，这会使得系统更难以改变和维护。因此，这里可以使用事件来防止这种直接调用的耦合。
此外，使用事件实现组件解耦也有其另外的，如果我们有一个只负责组件B的工作团队，那么他们则可能不需要与负责组件A的团队进行交流，直接针对组件A中的逻辑改变在组件B中做出相对反应。两个组件团队可以独立发展（banq注：微服务特点之一）， 我们的应用系统变得更灵活。
即使在同一个组件团队中，有时候我们不需要在同一请求/响应中立即执行一个动作的结果，只要异步执行这个动作，比如发送电子邮件。在这种情况下，我们可以立即向用户返回响应，并以异步方式发送电子邮件，并避免让用户等待发送电子邮件。
不过，如果我们不加区别地使用它，也有危险。我们会遇到逻辑流程的风险，这些逻辑流程在概念上是高度凝聚力的，但是通过采取脱钩机制的事件连接在一起。换句话说，应该在一起的代码将被分开，并且难以跟踪它的流程（类似于goto语句），不易于理解：可能是意大利面一样混在一起！
为了防止将我们的代码库变成一大堆意大利面条，我们应该将事件的使用限制在明确的情况下。根据我的经验，有三种使用事件的情况：
（1）去耦组件
（2）执行异步任务
（3）跟踪状态变化（审核日志）