connect systems with events

I am not an expert on this design pattern but I read something on it and my advice is: try not to forget the real purpose of this pattern. This time I found the article on Wikipedia really interesting. It is basically saying (at least it is what I understood) that this pattern has been "designed" to avoid creating too many dependencies, losing the decoupling. Here an example I took from the article:

Suppose there is a drawing function. This would be a "System" that iterates through all entities that have both a physical and a visible component, and draws them. The visible component could typically have some information about how an entity should look (e.g. human, monster, sparks flying around, flying arrow), and use the physical component to know where to draw it. Another system could be collision detection. It would iterate through all entities that have a physical component, as it would not care how the entity is drawn. This system would then, for instance, detect arrows that collide with monsters, and generate an event when that happens. It should not need to understand what an arrow is, and what it means when another object is hit by an arrow. Yet another component could be health data, and a system that manages health. Health components would be attached to the human and monster entities, but not to arrow entities. The health management system would subscribe to the event generated from collisions and update health accordingly. This system could also now and then iterate through all entities with the health component, and regenerate health.

I think that you overcomplicated your architecture, losing the advantages that this pattern can give you.

First of all: why do you need the EntityManager? I quote again:

The ECS architecture handles dependencies in a very safe and simple way. Since components are simple data buckets, they have no dependencies.

Instead your components are constructed with the EntityManager dependency injected:

entityManager.AddSystem(new Movement(entityManager));

The outcome is a relatively complex internal structure to store entities and the associated components.

After fixing this, the question is: how can you "communicate" with the ISystems? Again, answer is in the article: Observer Pattern. Essentially each component has a set of attached systems, which are notified every time a certain action occurs.