I have an event driven architecture where A is waiting for a change from B and B is waiting for a change from C and C is waiting for a change from A, forming a cycle.
Now, if B changes, then A fires an event to C, which fires to B, which fires to A, which fires to C…ad infinitum.
I can change my program right now to not contain this cycle, but I am concerned I may put myself into a corner at a later time where I cannot. How does one keep such things from happening when designing event based systems?
Cyclic dependencies are really bad. I had to write down your post in terms of A, B, and C before it even made sense to me. I think you should get rid of it. If you’re putting yourself in a corner, it’s probably a whole lot better than the problems you can run into with cyclic dependencies.
You can definitely avoid this, too. A, B, and C are really tightly coupled. I think you need to rethink their responsibilities. Perhaps there’s a common D element that’ll take a lot of your design-stress away.
Something else that comes to mind is architectural Layering. If you can layer A over B, and require communication by anyone speaking to B to go through A and down the layers, you might give yourself an easier time. Again, I don’t know much about your problem, so these are just broad suggestions.
One final option, and my least favorite, is to pass a message between each of the three components. As each is visited, require that each component add to the message that it has seen the message. Then the next component to get the message has information about who’s seen it. Kind of like a sign up sheet. But again, least favorite. Try something else first.
Good luck!