I definitely like the event-driven-architecture discussion. Just recently I was asked about how to link a couple of services together. It was described as â€˜orchestratingâ€™ but in essence, it was creating yet another service to sit in front of 2 and make 2 service calls and combine the data in returnâ€¦
Which in this read, you can see he points out:
The bigger question is how are these services linked (or coupled) together? â€¦
Your two choices would be EDA (event-driven architecture) or a "product" service. The former is the preferred method as the latter creates a single service (providing a potential single point of fail) which orchestrates interaction between the various services. The former is an architecture based on services publishing certain events which other services may subscribe to
The patterns I see emerging here is SOA kept loosely coupled, etcâ€¦ leads to a need for event-driven-architectureâ€¦ which then leads to the need for an enterprise service bus.
SOA â€“> EDA â€“> ESB
And then ESB is about business process modelling BPM
SOA â€“> EDA â€“> ESB â€“> BPM
Trying to decide which route to take. Iâ€™d prefer more convention over configuration if possibleâ€¦
Udi (create of NServiceBus) describes the architectural principles :
Service-Oriented Architecture and Event-Driven Architecture together
provide the basis for identifying where NServiceBus should be used.
Iâ€™ll end with this last quote:
Strategic Domain-Driven Design helps bridge the Business / IT divide
and drives the choice of business events published using NServiceBus.