Yazılım Mimarisi - Event Driven Architecture (EDA)

Diğer Mimariler İle Karşılaştırma

EDA vs Request Response

Açıklaması şöyle

Traditional applications on the web handle communication across boundaries over HTTP — via REST, GraphQL, RPC, and other specifications following the request/response model. This model is characterized by a requester sending a message, then waiting for a responder to receive, process, and reply to the message before continuing execution. Though this may take place in async functions in JavaScript, we can refer to this model as generally “synchronous” or “in-band,” in that a response is expected immediately following a request, and that the context executing the request will wait for it.

In EDA, also called the publish/subscribe model, the processes of requesting and receiving data are separate and performed in a non-blocking, asynchronous manner. Typically a client will subscribe to messages from a server, and a server will subscribe to messages from the client. When a client requests data, it simply sends a message, then carries on with its execution. The server receives this message, processes it, and at some point sends another message to the client. The client, as a subscriber, receives this message “out-of-band” from its original request, and processes the message as it sees fit. Critically, this can happen at another time, using a different network request, or even another protocol.

EDA vs Publish Subscribe Architecture

Açıklaması şöyle. 

An event driven architecture can use a pub/sub model or an event stream model.

Pub/sub: The messaging infrastructure keeps track of subscriptions. When an event is published, it sends the event to each subscriber. After an event is received, it cannot be replayed, and new subscribers do not see the event.

Event streaming: Events are written to a log. Events are strictly ordered (within a partition) and durable. Clients don't subscribe to the stream, instead a client can read from any part of the stream. The client is responsible for advancing its position in the stream. That means a client can join at any time, and can replay events.

Yani EDA daha genel bir mimari ismi. Publish/Subscribe ise özel bir broker/middleware tekniğine dayanıyor. Broker aboneleri takip etmekle sorumlu. 

EDA altta Publish/Subscribe tipi bir broker veya Event Streaming tarzı bir broker kullanabilir.

Publish Subscribe Architecture vs  Observer/Observable

Bu mimari ile Observer/Observable tasarım örüntüsü arasındaki en büyük fark, Observer örüntüsünde gözlemlenen kendisini gözleyen nesneleri bir liste halinde saklamasıdır. Gözlemlenen ve gözlenen her ne kadar bir arayüz vasıtasıyla konuşsalar da, birebir ilişki kurarlar.

Publish Subscribe mimarisi genellikle dağıtıktır ve bir ara katman vasıtasıyla iletişim olduğu için, birebir ilişki yoktur. Ayrıca bu mimari genellikle asenkron çalışır.

EDA vs RESTful Architecture

Açıklaması şöyle

While RESTful systems focused on resources, EVENTful solutions focus on actions. And, more importantly, EVENTful solutions rely on asynchronous interactions. This opens up many more possibilities for building responsive, real-time solutions. That means an EVENTful design offers services the ability to request and respond in real time and to do it in a way that provides more flexibility in the way the data is shared, displayed, and mixed across devices and platforms.

Mike Amundsen

EDA vs Event Sourcing

Event Sourcing aslında EDA'nın bir alt türevi. State'in event'ler dizisi halinde saklanması anlamına gelir. Açıklaması şöyle

Event sourcing is a much more special term, referring to systems that store all changes to the application state as a sequence of events. A well-known popular class of examples are transactional database systems, which store any state changes in a transaction log. Here, the term “event” refers more to “state change”, not only to “notification”.

Şeklen şöyle

EDA Nedir

Event-driven veya Event-Based mimarilerin genel özellikleri şöyle

EDA Nedir

Event-Based Pattern Nedir?
Açıklaması şöyle.

This is the most common distributed asynchronous architecture used to develop highly scalable system. The architecture consists of single-purpose event processing components that listen on events and process them asynchronously. The event-driven architecture builds a central unit that accepts all data and then delegates it to the separate modules that handle the particular type. 

Event, Command ve Query Farkı Nedir?

Aslında Event-driven mimaride her şeye event denmesi için bir eğilim var. Açıklaması şöyle

In conversations about event-driven architecture, it’s not uncommon that every message in the system is referred to as an event. While that may be acceptable in a casual conversation at the coffee machine, it is not when designing and implementing a (complex) system where it’s vital to use the right concepts in order to capture intent, in both design and code.

Ancak aslında 3 tane temel tip var, Bunlar Event, Command ve Query. Açıklaması şöyle.

All interactions taking place in an event-driven architecture are one of these three primitives: events, commands and queries.

Event Nedir?

Açıklaması şöyle

You can think of an event as an observable fact, something that has happened. In the context of event-driven architectures, Wikipedia describes an event as “a significant change in state”. The event is broadcasted, accompanied by relevant data, for other components in the system to act upon and thereby allowing side effects to occur. Events should not carry any expectation of future actions to be performed, or a response to be returned, as they merely represent a fact.

Command Nedir?

Açıklaması şöyle

Commands on the other hand, carry an authoritative instruction that there is specific work to be done. A command is sent and a specific receiver is expected to react. Often, an event happens off the back of a command being successfully processed, as this likely led to a significant change in state.
While the technical implementation of events and commands may be similar, the usage of clear naming to separate these concepts ensures that other engineers that come in can understand the intent and can build on that work. This is called the principle of least surprise, sometimes referred to as the principle of least astonishment. Now I am bound by craftsmanship ethics to link this cartoon because it is both funny and the truth.

Query Nedir?

Açıklaması şöyle

The final of the three primitives is the query, which is a request to retrieve internal state and return it to the caller. A query doesn’t cause any state changes or other side effects on the system. The most common implementation of a query is an HTTP GET request or a database query to retrieve data.

Event, Command ve Query Gerçekleştirimi

- Bu 3 temel tipi işleyen kodların nasıl gerçekleştirileceğini Command Query Responsibility Segregation - CQRS yazısına taşıdım.

- Bir başka Gerçekleştirim

Bu gerçekleştirimdeki yapıların isimleri şöyle

- event producers

- initial and processing events

- event routers

- event channels

- event consumers

Şeklen şöyle. Burada her şey event olarak düşünülüyor. Command ve Query yok

Şekildeki numaraların açıklaması şöyle. 

Example of an event-driven architecture for an e-commerce site. (1) — Event Producers; (2) — Initial Events; (3) — Event Router; (4) — Processing Events; (5) — Event Consumers

EDA Problemleri

Bazı problemler şöyle

1. Duplicate processing

2. Out of order processing

EDA Örüntüleri

Bazı örüntüler şöyle

- Event Notification

- Event-Carried State Transfer

- Queue-Based Load Leveling

- Asynchronous Request-Reply

- Claim Check

- Event Sourcing

- Command Query Responsibility Segregation (CQRS)

- Stream processing

EDA Best Practices

Açıklaması şöyle

1. Events are immutable.

2. Communicate events asynchronously.

3. Producers must guarantee “at least once” delivery.

4. Consumers must guarantee “at most once” delivery.

5. Consumers must be able to handle out-of-order messages.

6. Commands are different from events.

7. Define schemas for all events.

8. Define a versioning policy from day 1.

9. Avoid Upcasting at all costs.

10. Segregate event streams.

11. Event Sourcing is not an architectural pattern, Event-Driven is.

12. Event Sourcing does not replace auditing, if it is required.

13. Use a proper event store if implementing Event Sourcing.

14. Use DDD Aggregates.

15. Embrace eventual consistency.

16. Use Saga design pattern to maintain global business rules (invariants).

8. Define a versioning policy from day 1.

Açıklaması şöyle

 - Do not remove fields, deprecate them

 - Provide default value when introducing a new field

 - Introduce a new event should a breaking change be needed

9. Avoid Upcasting at all costs.

Açıklaması şöyle

Event upcasting means to transform it from its original structure to its new structure. Upcasters add technical debt IMHO

Şeklen şöyle