Skip to content

Commit cc502ac

Browse files
dgafkagitbook-bot
authored andcommitted
GITBOOK-908: No subject
1 parent d3fe560 commit cc502ac

File tree

4 files changed

+44
-9
lines changed

4 files changed

+44
-9
lines changed

.gitbook/assets/async-retry.png

57.1 KB
Loading

.gitbook/assets/event-handler.png

55.4 KB
Loading

.gitbook/assets/retry.png

44.5 KB
Loading

modelling/message-driven-php-introduction.md

Lines changed: 44 additions & 9 deletions
Original file line numberDiff line numberDiff line change
@@ -4,7 +4,7 @@ description: Message Driven System with Domain Driven Design principles in PHP
44

55
# Introduction
66

7-
## The foundation idea
7+
The foundation idea
88

99
The roots of Object Oriented Programming were mainly about communication using Messages and logic encapsulation. The aim was to focus on the flows and communication, not on the objects itself. Objects were meant to be encapsulating logic, and expose clear interfaces of what they do, and what have they done.
1010

@@ -177,26 +177,37 @@ class NotificationSender
177177
}
178178
```
179179

180-
This Event Handle will be automatically triggered when related Event will be published. \
181-
As we mentioned at the beginning of this introduction, communication happen through Message Channels, and it's really easy to switch code from synchronous to asynchronous. For that we would simply state that this Handler should be asynchronous:
180+
This Event Handler will be automatically triggered when related Event will be published. \
181+
This way we can easily build decoupled flows, which hook in into existing business events. 
182+
183+
{% hint style="success" %}
184+
Even so Commands and Events are Messages at the fundamental level, Ecotone distinguish them because they carry different semantics. Commands are meant to state intention of what we want to happen, and Events carry the information about what have had happened in our System. \
185+
\
186+
By this design Commands can only have single related Command Handler, yet Events can have multiple subscribing Event Handlers.
187+
{% endhint %}
188+
189+
[Click, to find out more...](command-handling/external-command-handlers/event-handling.md)
190+
191+
### Asynchronous Processing
192+
193+
As we mentioned at the beginning of this introduction, communication happen through Message Channels, and it's really easy to switch code from synchronous to asynchronous. For that we would simply state that given Message Handler should be executed asynchronously:
182194

183195
```php
184196
#[Asynchronous("async")]
185197
#[EventHandler]
186198
public function when(UserWasRegistered $event): void
187199
```
188200

189-
Now before this Event Handler will be executed, it **will land in Asynchronous Message Channel** named "async" first. 
201+
Now before this Event Handler will be executed, it **will land in Asynchronous Message Channel** named **"async"** first, and from there it will be consumed asynchronously by Message Consumer (Worker process).
190202

191203
{% hint style="success" %}
192-
There maybe multiple Event Handlers subscribing to same Event Message. \
193-
We can easily imagine that some of them may fail and things like retries become problematic (As they may trigger successful Event Handlers for the second time).\
204+
There maybe situations where multiple Asynchronous Event Handlers will be subscribing to same Event. \
205+
We can easily imagine that one of them may fail and things like retries become problematic (As they may trigger successful Event Handlers for the second time).\
194206
\
195-
That's why Ecotone deliver a copy of the Message to each related Event Handler. \
196-
As a result each Asynchronous Event Handler is handling it's own Message in full isolation, and in case of failure only that Handler will be retried.
207+
That's why Ecotone introduces [Message Handling isolation](recovering-tracing-and-monitoring/message-handling-isolation.md), which deliver a copy of the Message to each related Event Handler separately. As a result each Asynchronous Event Handler is handling it's own Message in full isolation, and in case of failure only that Handler will be retried.
197208
{% endhint %}
198209

199-
[Click, to find out more...](command-handling/external-command-handlers/event-handling.md)
210+
[Click, to find out more...](../quick-start-php-ddd-cqrs-event-sourcing/asynchronous-php.md)
200211

201212
### Aggregates
202213

@@ -328,6 +339,30 @@ We have been building stateless workflows here, however Ecotone provides also st
328339

329340
While working with Ecotone's Message Driven Architecture, a lot of things that previously felt hard, or inaccessible will now become natural and easy. And this is not in relation to building business workflows, there is much more that Ecotone provides out of the box. This includes implementation of patterns which help with resiliency and scalability, ability to test synchronous and asynchronous components in isolation, event sourcing and projecting support and many more. However those are out of the scope of Introduction section.
330341

342+
### Resilient Architecture
343+
344+
Ecotone handles failures at the architecture level to make Application clear of those concerns. \
345+
As Messages are the main component of communication between Applications, Modules or even Classes in Ecotone, it creates space for recoverability in all parts of the Application. As Messages can be retried instantly or with delay without blocking other processes from continuing their work. 
346+
347+
<figure><img src="../.gitbook/assets/event-handler.png" alt=""><figcaption><p>Message failed and will be retried with delay</p></figcaption></figure>
348+
349+
As Message are basically data records which carry the intention, it opens possibility to store that "intention", in case unrecoverable failure happen. This means that when there is no point in delayed retries, because we encountered unrecoverable error, then we can move that Message into persistent store. This way we don't lose the information, and when the bug is fixed, we can simply retry that Message to resume the flow from the place it failed.
350+
351+
<figure><img src="../.gitbook/assets/retry.png" alt=""><figcaption><p>Storing Message for later review, and replaying when bug is fixed</p></figcaption></figure>
352+
353+
There are of course more resiliency patterns, that are part of Ecotone, like:&#x20;
354+
355+
* Automatic retries to send Messages to Asynchronous Message Channels
356+
* Reconnection of Message Consumers (Workers) if they lose the connection to the Broker&#x20;
357+
* Inbuilt functionalities like Message Outbox, Error Channels with Dead Letter, Deduplication of Messages to avoid double processing,&#x20;
358+
* and many many more.&#x20;
359+
360+
{% hint style="success" %}
361+
The flow that Ecotone based on the Messages makes the Application possibile to handle failures at the architecture level. By communicating via Messages we are opening for the way, which allows us to self-heal our application without the need for us intervene, and in case of unrecoverable failures to make system robust enough to not lose any information and quickly recover from the point o failure when the bug is fixed.
362+
{% endhint %}
363+
364+
[Click, to find out more...](recovering-tracing-and-monitoring/resiliency/)
365+
331366
## Business Oriented Architecture
332367

333368
Ecotone shifts the focus from technical details to the actual business processes, using **Resilient Messaging** as the foundation on which everything else is built. It provides seamless communication using Messages between Applications, Modules or even different Classes.

0 commit comments

Comments
 (0)