Svelto.ECS/ECS/note.txt

systems do not hold component data, but only system states
systems cannot be injected
systems are SRP and OCP
systems communicates between component, mediators, producer/consumer, Svelto.ECS.Example.Observers. producer/consumer and observers must be defined in the layer of the engine.
systems can have injected dependencies

components don't have logic
components can have only getter and setter
components cannot define patterns that requires logic.
components cannot issues commands

High Cohesion[edit]
Main article: Cohesion (computer science)
High Cohesion is an evaluative pattern that attempts to keep objects appropriately focused, manageable and understandable. High cohesion is generally used in support of Low Coupling. High cohesion means that the responsibilities of a given element are strongly related and highly focused. Breaking programs into classes and subsystems is an example of activities that increase the cohesive properties of a system. Alternatively, low cohesion is a situation in which a given element has too many unrelated responsibilities. Elements with low cohesion often suffer from being hard to comprehend, hard to reuse, hard to maintain and averse to change.[3]

Low Coupling[edit]
Main article: Loose coupling
Low Coupling is an evaluative pattern, which dictates how to assign responsibilities to support:

lower dependency between the classes,
change in one class having lower impact on other classes,
higher reuse potential.

events, observers and mediators have the inconvience to hold the reference to the engine, which forces to use cleanup if the engine must be removed. 
Observers are easy to clean up from the engine. Mediators needs to be integrated to the framework to be simple to clean up. Component events need the clean up function.
producer/consumer has the inconvienent to force check the number of jobs available everyframe

Engine can't be removed, they can only be disabled, but the logic of disabling must be handled by the engine itself

Should components have just one element? Should engines use just nodes? Components are ditacted by the entities and Nodes by the engines

http://thelinuxlich.github.io/artemis_CSharp/

differences: components no events, everthing must be update
give more responsabiltiy to the user, semplicity

https://github.com/sschmid/Entitas-CSharp/wiki/Overview

no groups, no queries

http://entity-systems.wikidot.com/es-articles

http://www.ashframework.org/

it's very important to give a namespace to the engines. In this way it's impossible to create semantically wrong nodes (PlayerNode Vs TargetNode)

ToDo:

it's not safe to remove an engine without having called being denitialised internal states. A special ClearOnRemove function must be added for each engine

namespace GameFramework.RayCast
{
    public class RayCastEngineEngine
    {
        public RayCastEngine(RayCastEmployer jobList)
        {
            jobList.onJobassigned += OnRaycastRequested;
        }

        public void Add(IComponent obj)
        {}

        public void Remove(IComponent obj)
        {}

        void OnRaycastRequested(RayCastJob job)
        {
            RaycastHit shootHit;

            Physics.Raycast(job.rayVector, out shootHit, job.range, _enemyMask);

            job.Done(shootHit);
        }

        RayCastEmployer                     _employer;
                
        int                                 _enemyMask;
    }

    public struct RayCastJob
    {
        readonly public Ray rayVector;
        readonly public float range;
        readonly public Action<RaycastHit> Done;

        public RayCastJob(Ray direction, float distance, Action<RaycastHit> OnDone)
        {
            rayVector = direction;
            range = distance;
            Done = OnDone;
        }
    }

    public class RayCastEmployer
    {
        public event Action<RayCastJob> onJobassigned;

        public void AssignJob(RayCastJob data, Action<RaycastHit> onJobdone)
        {
            onJobassigned(data);
        }
    }
}

if your code can be read as

A tells B to do something is direct
A register B event is indirect
althoggh if B tells A something through event is direct again. B must say something like I don't know who you are, but this just happened. you say B.SomethingHappenedToMe() not B.YouMustDoThis(); 

un engine non deve mai avere concetti di un altro engine. dire all'engine sonoro suona morte � sbagliato. � l'engine death che triggera l'evento e l'engine sound ad ascoltarlo.