DDD:Event Driven Architecture

领域驱动设计系列

Posted by Shoukai Huang on March 18, 2020

定义&概念

事件

一个事件可以被定义为“在显著变化状态” —— 维基百科

An event can be defined as “a significant change in state”.

事件代表着不同的东西,简短归类为如下四种 —— Martin Fowler

The biggest outcome of the summit was recognizing that when people talk about “events”, they actually mean some quite different things. So we spent a lot of time trying to tease out what some useful patterns might be. This note is a brief summary of the main ones we identified.

  1. 事件通知(Event Notification):当系统发送事件消息以将其域中的更改通知其他系统时,就会发生这种情况。
  2. 事件进行状态转移(Event-Carried State Transfer):当您要以不需要为进一步工作而联系源系统的方式更新系统的客户端时,就会显示此模式。
  3. 事件溯源(Event-Sourcing):事件源的核心思想是,每当我们更改系统状态时,我们都会将状态更改记录为事件,并且可以在将来的任何时候通过重新处理事件来自信地重建系统状态。
  4. CQRS:命令查询责任隔离(CQRS)是具有用于读取和写入信息的独立数据结构的概念。

EDA

事件驱动架构(EDA)是一种软件体系结构范例促进生产、检测、消费和响应事件 —— 维基百科

Event-driven architecture (EDA) is a software architecture paradigm promoting the production, detection, consumption of, and reaction to events.

事件驱动架构模式是一种流行的分布式异步架构模式,用于生成高度可扩展的应用程序。 —— Mark Richards(Author of Software Architecture Patterns)

The event-driven architecture pattern is a popular distributed asynchronous architecture pattern used to produce highly scalable applications.

Event structure

事件可以由两部分组成,即事件标头和事件主体。事件标头可能包含信息,例如事件名称,事件时间戳和事件类型。事件主体提供检测到的状态更改的详细信息。事件主体不应与可对事件本身发生的反应所应用的模式或逻辑相混淆。

An event can be made of two parts, the event header and the event body. The event header might include information such as event name, time stamp for the event, and type of event. The event body provides the details of the state change detected. An event body should not be confused with the pattern or the logic that may be applied in reaction to the occurrence of the event itself.

Event flow layers

事件驱动的体系结构可以建立在四个逻辑层上,检测事件开始,继续以事件结构的形式创建其技术表示,并以对该事件的一组非空反应作为结尾

An event driven architecture may be built on four logical layers, starting with the sensing of an event (i.e., a significant temporal state or fact), proceeding to the creation of its technical representation in the form of an event structure and ending with a non-empty set of reactions to that event

  • Event generator(事件生成器)
  • Event channel(事件管道)
  • Event processing engine (事件处理引擎)
  • Downstream event-driven activity (下游事件驱动活动)

Event processing styles

事件处理有三种通用样式:简单,流和复杂。这三种样式通常在成熟的事件驱动的体系结构中一起使用。

There are three general styles of event processing: simple, stream, and complex. The three styles are often used together in a mature event-driven architecture

  • Simple event processing
  • Event stream processing(事件流处理(ESP))
  • Complex event processing(复杂事件处理(CEP))
  • Online event processing (在线事件处理(OLEP))

架构模式

事件驱动的架构模式由两个主要拓扑组成:the mediator(媒介拓扑)和 the broker(经纪人拓扑) (翻译存在歧义,不再翻译该名词)

  • Mediator Topology:当您需要通过中央调解器协调事件中的多个步骤时,通常使用 mediator 拓扑
  • broker Topology :当您希望将事件链接在一起而不使用中央中介程序时,将使用代理拓扑

Mediator Topology

Mediator 拓扑结构对于具有多个步骤并且需要某种编排级别的事件才能处理的事件很有用。

The mediator topology is useful for events that have multiple steps and require some level of orchestration to process the event.

Broker Topology

Broker 拓扑与 Mediator 拓扑的不同之处在于,不存在中央事件中介器。相反,消息流通过轻量级消息代理(例如ActiveMQ,HornetQ等)以链状方式分布在事件处理器组件中。当您具有相对简单的事件处理流程并且不需要(或不需要)集中事件编排时,此拓扑很有用。

The broker topology differs from the mediator topology in that there is no central event mediator; rather, the message flow is distributed across the event processor components in a chain-like fashion through a lightweight message broker (e.g., ActiveMQ, HornetQ, etc.). This topology is useful when you have a relatively simple event processing flow and you do not want (or need) central event orchestration.

适用范围

此体系结构模式可以通过在松散耦合的软件组件和服务之间传输事件的应用程序和系统的设计和实现来应用

This architectural pattern may be applied by the design and implementation of applications and systems that transmit events among loosely coupled software components and services.

具体场景:

  • 多个子系统必须处理相同的事件。
  • 以最小的时间延迟进行实时处理。
  • 复杂的事件处理,例如模式匹配或时间窗口上的聚合。
  • 大量和高速的数据,例如物联网。

Benefits

  • 生产者和消费者是分离的。
  • 没有点对点集成。 向系统添加新使用者很容易。
  • 消费者可以在事件到达时立即对其做出响应。
  • 高度可扩展和分布式。
  • 子系统具有事件流的独立视图。

Challenges

可靠机制:在某些系统中,尤其是在IoT场景中,至关重要的是确保事件得以交付。 顺序及恰好一次:按顺序或仅一次处理事件。 每种使用者类型通常都在多个实例中运行,以实现弹性和可伸缩性。 如果必须按顺序处理事件(在消费者类型内),或者处理逻辑不是幂等的,这可能会带来挑战。

参考