ECS模型有Entity元素、Component元素和System元素组成，在机器这个物理环境下，它们是有“生存期”特点的。
Entity之间可以通信、Component之间也可以通信。通信的方式可以是多样的，包括：
对于游戏来说，每个模块应该专注于干好一件事，而每件事要么是作用于游戏世界里同类的一组对象的每单个个体的，要么是关心这类对象的某种特定的交互行为。比如碰撞系统，就只关心对象的体积和位置，不关心对象的名字、连接状态、音效、敌对关系等。
在演讲中，作者谈到了一个根据输入状态来决定是不是要把长期不产生输入的对象踢下线的例子，就是要对象同时具备连接组件、输入组件等，然后这个AFK处理系统遍历所有符合要求的对象（自调整），根据最近输入事件产生的时间，把长期没有输入事件的对象通知下线；他特别说到，AI控制的机器人，由于没有连接组件，虽然具备状态组件，但不满足AFK系统要求的完整组件组的要求，就根本不会遍历到，也就不用在其上面浪费计算资源了。
ECS和传统的面向对象或是Actor模型是截然不同。OO或Actor强调的是对象自身处理自身的业务，然后框架去管理对象的几何，负责用消息驱动它们。而在ECS种，每个系统关注的是不同的对象集合，它处理的对象中有共性的切片。
并不是所有的问题都适合遵循ECS的规范来开发，尤其是一些旧有的模块，很难做到把数据结构按Component的规范暴露出来，并把状态改变的方法集成到独立的System中去。这个时候应该做些封装的工作。比如有些系统原本就利用了多线程模型并行优化，所以我们需要把这些已经做好的工作隔离在ECS框架之外，仅仅暴露一些接口和ECS框架对接。（用户输入流读取，状态变化，只有一个线程，非纯函数，不适合System的介入）
感想：每个模块都有自己的使命，不是万能通用的。也许这更符合机器的特性。