Since attending Udi's ADSD class about a year and a half ago, the publish/subscribe pattern in general has been fascinating for me to consider at many levels. In some ways it's a fundamental shift in the way we program. When we're kids we learn how to ride bikes, and from then on we just hop on any bike and ride it without even thinking. When we're beginner programmers we learn how to call methods, and from then on that's what we do - we write methods and we call them without even thinking about it.

The downside is that this creates dependencies all over the place. These dependencies rear their ugly head in a large project that is now in maintenance mode. Consider a system that accepts membership applications from end users - here is some pseudo code that describes a high-level communication between the Application System and the Payment System.

class ApplicationSystem {

   void SubmitApplication() {
      PaymentSystem.ChargeForApplication();
   }

}

Now the Application System is deeply tied to the Payment System, and has to know business logic about when to charge, which really should be the sole responsibility of the Payment System. The business concern of paying for applications should be as decoupled as possible from the business concern of processing applications. The Publish/Subscribe pattern allows this:

class ApplicationSystem {

   Sub SubmitApplication() {
      RaiseEvent("ApplicationSubmitted")
   }

}

Key point: The Application System no longer depends on the Payment System. But the same functionality as before can be implemented if the payment system subscribes to the ApplicationSubmitted event.

Consider this: The business changes and decides that instead of charging users when they submit their application they want to charge upon approval of the application.

Request/Response Modification: Application System has to change quite a bit to call the right methods of the Payment System at the right time.

Publish/Subscribe Modification: Application System doesn't change at all; Payment System listens for "ApplicationApproved" instead of "ApplicationSubmitted."  Pub/sub FTW!

Bottom Line: Divide large systems into smaller subsystems, and when it comes to integration of these subsystems use a publish/subscribe pattern instead of a request/response pattern. It'll turn your thinking on its head for a while, but the end result will be a more decoupled system that's easier to maintain.