架构层级的“开闭原则”（the-Open-Closed-Principle，简称OCP原则）含义是：一个类对扩展是“开”放的，而对变更是封“闭”的，意思是说，应该在不改变类的前提下扩展一个类的行为。而通常的方式是继承和多态。在架构层级，我们并不会变更系统的一部分功能（可能是最适用于当前架构的进程，守护进程，服务，或者微服务），而是通过新增功能的方式来复用已完成的代码。为了不对现有的部分做出变更，系统需要做到完全的解耦。接下来的内容将聚焦于事件驱动系统，并以消息队列实现服务间通信。消息队列可以是ActiveMQ,RabbitMQ,ZeroMQ,Kafka或者其他服务，我将以Kafka的话语体系来进行描述，如主题（Topic），发布者，订阅者，以及类似Kafka的多个订阅者共享相同主题的能力。
迪米特法则（Law of Demeter）又叫作最少知识原则（Least Knowledge Principle 简称LKP），就是说一个对象应当对其他对象有尽可能少的了解。事件主要的目标就是传达某事已经发生的消息，并提供与这一事情相关的有用的数据。用于为系统构建数据流的事件，一般是应用于大数据系统中。在大数据系统中充斥着横跨系统范围内大量的信息，信息在传递过程中会经过多次转换。可以让事件附加我们所能提供的尽量多的信息，以便减少在信息转换所带来的额外的成本。我们所能采取的最好的方案是，在消息中提供足够的信息，既满足我们最初的设计中所考虑到的用例场景的需要，同时也要让这些信息对我们可能尚未考虑到的新的服务是可用的。比如把主要的有界上下文的实体的ID引入 进来，这些实体要么是我们与事件通信的事实的一个组成部分，要么与之相关。新的微服务需要涵盖很多的实体，当然，这会打破“迪米特法则”，但这是必要的妥协。软件架构的要义即在于此：做出恰当的权衡以达成尽量好的系统。遵循开闭原则的能力是如此的重要而有意义，从某种程度上讲，我们可以为此不惜违背“迪米特法则”。
1、事件驱动系统给了我们很好的机会来在架构层级应用开闭原则。我们可以重用已有的代码，并且在未知的方向上实现功能的扩展。
2、然而，需要谨慎的设计事件的内容，同时警惕糟糕的设计可能引入的耦合的可能性。
3、要根据系统的目标来指导架构设计，为某一目标设计某种适用的架构（如，为大数据系统设计的流式数据）很可能对于另一目标来说是糟糕的设计（不适用于表征事实发生的事件驱动系统）。
4、领域驱动设计的有界上下文可以为事件内容的设计提供一些指导。
5、架构是关于决策和权衡，最大化应用开闭原则很可能意味着对“迪米特法则”的最小化遵循，必须谨小慎微地寻找一个平衡点。