anchor.diff:  .  Regular workload : software that run at regular rate, kind of ballance trade off between performance and complexity
   .  Simple dataflow: the flow of the data is easy to watch, inspect, start stop, manipulate. As the root reason for regular workload!
   
  -```
  +
   Ideas similarities here actually is resulted from with decades of history of revolving of the paradigm. That's why you will see the same concepts of Entity system appear every where from a database to a repository. Of course because it have the same root.Check Pros and Cons chapter for full, detailed idea and design goals and successes.
  -```
  +
   
   
   == Terms
  
positive.code: 
  *Why this section havs things from the Cons section but consider differrently?*
  
  ```
  In Cons section descible problem should be concerned, likely to be done wrong, or the limit of the design they can be solve in implementations or not is not important!
  ```
  
  ```
  Known issue is the problem persist in even the well designed; or persist due to the underlying infrastructure, application, programming language, etc!!
  ```
  
  
  ==== Communication:
  
  Happen in non pure data solution, when Components don’t function independently of each other. Some means of communication is necessary
  • Two approaches (both viable):
  
  ```
  – Direct communication using dynamic cast and function calls
  – Indirect communication using message passing
  ```
  
  In pure data solution, by not query or just loop through interested component at one update cycle, the Processor eases out the need of other communication, but in complex scenario, such as combine with outter event handling such as Network, where message passing is nature, the problem still persist!
  
  
negative.code: Read: link:http://blog.gemserk.com/2011/11/13/scripting-with-artemis/[http://blog.gemserk.com/2011/11/13/scripting-with-artemis/]
  
  Nearly one end up back to half ass solution, not a pure data ES if their really need scripting in.
  
  
  ==== Arbitrary Routine and Query
  