Finally, I came to a conclusion that it is better to remove all entities that have associated visuals in one place. Considering situation where I have, say, particle emitter that can turn on some event and then shall stay until the entity is destroyed. Trying to keep it more MVC I always end up with some linking hashmaps that have potential leaks in case entity was killed in logic. In this case my particle emitter system will never know that this emitter has to disappear. The other side is that I can have multiple requests to emit one emitter, and from different entities in different times so they will stack and slow down fps which is not desired behaviour. So I think of some visualstate processing system that will process only its dedicated component and will cover sync between actual entity state and its visuals. In this case I have to be sure that I will “receive” entity with this component, thus it’s better to kill them all in one place, to be sure that necessary entities for visual finalizing were all created. Is that right?
Hm… The general rule is that only one system should ever create or change one type of components while multiple other systems can read it…
So for effects you’d have an entity that the effect is bound to (e.g. a NPC) and an entity for the effect itself (probably linking the original entity that its bound to in a component). Your effects system should then be able to check if the original entity still has all components that make it “stay” in the world and be able to remove the effect based on that.
Hmm… well let’s assume my entity got “killed” in logic. In this case I can create component of type “Kill” that will contain EntityId of what was killed and will be then processed by visual system (say, by detaching one of emitters). It is all well and good, but then the question of removing the component itself is easier to do in visual system (as it knows when it has been processed) than in logic that has no clue of was it already processed or not? In this case I need only one-way link, not both ways, don’t I?
It gets killed, so you either remove the “IsAliveAndVisibleComponent” or add a “IsDead” component… The effects have a “OriginEntity” component. The EffectsSystem checks the OriginEntity and removes the effect because is “IsDead”… Otherwise again, only one system should ever add, change or remove one type of component.
The visuals should not control the back end. The back end has to know what kind of time things take and operate accordingly. This is the kind of thing I use the Decay component and decay system for. It’s only job is to watch for entities with Decay components and delete them at the appropriate time (which could be instant, too).
I’m not sure I understand why you’d have a kill component point to some other entity and not just attach it to the entity to be killed. Seems like an unnecessary indirection to me.
Thanks for the responses, I’ll try to get there today 
Update: yep, it is done now. Everything was solved quickly and transparently just after adding one tiny component HasVisual. My problem was that I was trying to make it work being stuck just with the existing structure. Thanks a lot, normen.
And yes, Paul, I’ll keep what you said in mind (especially for the future when it hopefully comes to client-server things).