En este capítulo, pasaremos de tener un eventbus opcional a usarlo como el punto de entrada principal de la app. Un message processor
A New Requirement Leads Us to a New Architecture
Basicamente, Shit happens. Hacemos el software buscando modelar procesos del mundo real. El mundo es caótico: la gente es unreliable, lo que lleva a que sucedan cosas inesperadas.
The Message Bus Now Collects Events from the UoW
Instead of having the UoW push events onto the message bus, we will have the message bus pull events from the UoW.
Result
- What used to be service-layer functions are now event handlers.
- That makes them the same as the functions we invoke for handling internal events raised by our domain model.
- We use events as our data structure for capturing inputs to the system, as well as for handing off of internal work packages.
- The entire app is now best described as a message processor, or an event processor if you prefer.
Whole app is a message bus: the trade-offs
| Pros | Cons |
|---|---|
| Handlers and services are the same thing, so that’s simpler. | A message bus is still a slightly unpredictable way of doing things from a web point of view. You don’t know in advance when things are going to end. |
| We have a nice data structure for inputs to the system. | There will be duplication of fields and structure between model objects and events, which will have a maintenance cost. Adding a field to one usually means adding a field to at least one of the others. |
| Chapter 10 - Commands |