I came to this book with a background in SoA principles, real-life experience implementing dozens of web services over HTTP in Java (some lightweight, some using full object models in SOAP, some in SOAP with XML CLOBs, some REST-like) and I was looking for a practical survey of how to go about converting your developer's mindset of a typical Web Services/SoA setup into one that supports real EDA, and provides the flexibility required - that I've always noted has been lacking from the designs I have previously implemented. I don't really feel like I got this from this book. I felt like it too quickly eschewed commentary on the specific difficulties in implementing web services like the ones described, instead asserting that merely thinking in an EDA mindset (storing as much state in the message as possible, use pub-sub etc) was enough to ensure the long-term *ilities of your architecture, without really /demonstrating/ how this worked in practice. For example, I didn't really feel like the book covered principles of how to design your SOAP (or other) schemas in such a way to allow your event state models to change over time, whether to publish different "versions" of an event type to different messaging endpoints, how to handle events which can only be handled by one instance of a service (but need to have redundancy and load balancing) -- or other approaches to managing change in your event producers and consumers. I also felt like it accepted UDDI as the solution to service location without criticism; I'd at least expect some commentary on drawbacks or alternatives.
Many such practical concerns when choosing frameworks and the practical concerns with designing such systems seem to have been left as "implementation detail" despite the heavy focus on Governance in later sections making quite a lot of noise about the importance of standardisation and policy. What about the theory and best practice that should go into designing these policies?
Perhaps I was expecting too much from a relatively short book; I just felt that to separate itself from the many SoA books on the market required more detailed analysis (and I mean getting closer to implementation) of the best practice and implementation considerations (i.e. expanded "EDA core components" and "EDA patterns" sections.)
On the plus side, the book is written well, in a good style and generally makes good use of diagrams when necessary, and it's a good overview of the subject area. I found it enjoyable to read. I also agree with many of its conclusions, just was looking for more discussion of ways around the drawbacks to implementing EDA -- other than "make sure you have stakeholder buy in", as in the later sections. Given the "level" of roles the writers are in, perhaps I was expecting the wrong thing from this book in wanting more of a bridge to implementation by developers.