You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: modelling/message-driven-php-introduction.md
+44-9Lines changed: 44 additions & 9 deletions
Original file line number
Diff line number
Diff line change
@@ -4,7 +4,7 @@ description: Message Driven System with Domain Driven Design principles in PHP
4
4
5
5
# Introduction
6
6
7
-
## The foundation idea
7
+
The foundation idea
8
8
9
9
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.
10
10
@@ -177,26 +177,37 @@ class NotificationSender
177
177
}
178
178
```
179
179
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:
182
194
183
195
```php
184
196
#[Asynchronous("async")]
185
197
#[EventHandler]
186
198
public function when(UserWasRegistered $event): void
187
199
```
188
200
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).
190
202
191
203
{% 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).\
194
206
\
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.
197
208
{% endhint %}
198
209
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)
200
211
201
212
### Aggregates
202
213
@@ -328,6 +339,30 @@ We have been building stateless workflows here, however Ecotone provides also st
328
339
329
340
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.
330
341
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><imgsrc="../.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><imgsrc="../.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: 
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 
357
+
* Inbuilt functionalities like Message Outbox, Error Channels with Dead Letter, Deduplication of Messages to avoid double processing, 
358
+
* and many many more. 
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
+
331
366
## Business Oriented Architecture
332
367
333
368
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