To understand why zero coupling is not realistic — or that it doesn’t necessarily solve all problems — let’s circle back to the definition of coupling, using the services instead of modules: “…the degree of interdependence between services”.

Zero coupling means two services have no interdependence, which effectively means that Service A does not depend on Service B to carry on with its responsibilities. But what about Service B? At first you may say the same applies, but let’s take a closer look.

Figure 5. Order service is decoupled from the payment service as it does contact it directly.

Figure 5 illustrates that although the order service is unaware of the payment service, the latter needs to know what an OrderPlaced event means and understand its contents enough to carry on with its expected behavior of capturing the payment.

Figure 6. Payment Service policy needs to know that an order was placed so the amount has to be captured.

Now, imagine that the business decides to offer pre-orders and the logic is that you should capture just a specific amount instead of the entire value. They decided to update the contract to reflect that.

In this case, your payment service needs to be updated to understand the new contract and its expected behavior.

Figure 7. Payment Service needs to be updated to understand the changes in the Order.

This indicates that even though there is no coupling of the order service with the payment service, the same can’t be said for the payment service. So, the expectation that an EDA provides zero coupling is not actually true.

While this is not to say that EDA is a bad choice, there are some challenges associated with its adoption that can’t be neglected. Let’s quickly review some of them.