There is still coupling in Event-Driven Architectures (EDAs)! Coupling means changes on one side have to propagate to the other side and it can be measured in multiple dimensions. Even in EDAs, there are multiple forms of coupling: * Technology: if the publisher chooses to use a different event bus technology, then the consumer has to adapt. * Format: if the publisher changes the format of the event messages (e.g. to adopt the CloudEvents standard), then the consumer has to update accordingly. * Semantic: if the publisher changes the meaning of the data attributes, then the consumer has to change the way it handles them. Coupling gets thrown around a lot, but few people actually get into the nuance like Gregor Hohpe. If you haven't read it already, check out his article on the many facets of coupling here: https://buff.ly/4bh3wxH and how these apply to Event-Driven Architectures here: https://buff.ly/3OV8YgP These changes propagate from the publisher to consumers, as they have an upstream-downstream relationship. Context maps in DDD help us visualise these relationships and identify situations where, for example, we should employ techniques such as Anti-Corruption Layers (ACLs) to help protect the downstream system from upstream changes and minimize their blast radius. To learn about context mapping and the different forms of relationships, check out my video on the topic: https://buff.ly/4fmfRTl and this is how you can implement ACLs with EventBridge and Lambda: https://buff.ly/4finCK2 Ok, that's quite a few things I've thrown your way, if anything's not clear, please feel free to ask me in the comments!
Yan Cui Indeed, the concept of coupling in EDAs is often underestimated. Your mention of technology, format, and semantic coupling highlights crucial considerations that can significantly affect system integration and functionality. Gregor Hohpe’s insights on this topic are indeed invaluable for anyone dealing with EDAs. Implementing strategies like Anti-Corruption Layers (ACLs), as you suggested, is a proactive approach to safeguard downstream systems from upstream changes, thereby minimizing potential disruptions. Excellent resources and explanations on this complex topic—thank you for sharing!
Principal Engineer at AWS | I help software organizations anticipate, withstand, respond, and learn from failures using resilience and chaos engineering principles.
2dWhile I agree, I think this is a semantic issue rather than not understanding the nuances. Most people think of (de)coupling as components having (or not) __deep__ knowledge of each other. This is also why we typically define coupling with an adjective in front, like loose or tight coupling. Format, semantics, and tech are (usually) more of the loose coupling camp, whereas db schema and syntax in the code are more tight coupling. Feels a bit the same discussion as lock-in. It is also about shifting complexity around... (similarly to what Werner talked about in his keynote). Great post from Gregor though. Very detailed.