接下来明确四个管道的存在意义：
1.Errors(think for error，not success)：

处理过程中任务：有一些Error可能需要转化为event如IO01，IO02
处理结束任务：发送ps(pr)至各个ps服务器

2.Events:

处理过程中任务：不仅仅处理server包，client包，rn包的“事件”，虽然其属于service包，也要处理service包
处理结束任务：发送ps(ps)至各个ps服务器
由于上面所描述的处理过程中任务，析构的时候他需要被作为service包最后一个被关闭的对象

3.Dates:

处理过程中任务：聚合modbus等自机数据源，似乎Dates几乎不可能在这过程中被转化为Errors或者Events 处理结束任务：发送ps(ps)至各个ps服务器

4.Modbus:(已合并)

~~server端主动发出的数据(是否需要与Dates合并呢？)~~  
~~也可以描述为“自机信号发生器”，如果强调其“发生”的意义，那么就需要让他与datesBox进行对接了~~  
~~同时~~他也不适合再被称为Modbus，因为Modbus只是一种“符合modbus协议的格式”，并不代表以后所有需要进行“自机信号发生”的字符串都是modbus  
最起码以后也可能会是snmp协议，或者发送短信的AT协议  

目前看来上述描述的思路确实是合理的，那么他到底需不需要与dates进行对接呢？
目前唯一能想到的是Errors与Events的对接是合理的很不合理

以及Events与Dates的对接似乎也是合理的，等等，“Events与Dates的对接？”之前确实还没考虑过，考虑清楚这个，也就自然而然想明白“目前的ModbusBox与DatesBox了
上述思路是错的，因为：

让service各个管道在“处理结果后的状态下”继续进行数据交换，这个思路是完全不符合解耦逻辑的！，直接讲数据进行pub才型