决定版补充

上面这张图，对于决定版架构来说，已经过时了，在决定版架构中，很少遇到需要跨模块发送事件的情况，因为我们引入了层级这个概念，同时在对象之间交互的额方法中又多了一个Command（包括Query），再加上Command——Model——StateChangedEvent模式，基本上跨模块之间发送消息的情况就比较少见了。

对象之间的交互一开始只专注在两个对象之间，目前可以是：

调用方法
委托
事件
命令（包括Query，包含CQRS原则）

最佳实践就是：

自顶向下可以调用方法和命令
自底向上可以用委托和事件通知

决定版架构的出现其实参照了网络客户端-服务器的开发理念。

服务器可以理解为底层，客户端可以理解为表现层。

客户端与服务器的通信一般如下：

Http请求（如果是增删改，比如说Post、RESTfull API，就有点像Command，如果是查询，就像是Query，有点像委托调用）
TCP长连接（连接之后有点像发送事件，服务器能够主动通知客户端）
UDP（像发送事件）
RPC（模拟方法调用，Remote Process Call，远程进程调用）

服务器和和客户端的通信都需要序列化和反序列化，架构中的Command和Query也可以进行序列化和反序列化。

我们有了决定版架构的使用经验，就可以很快抓住其他领域的开发重点，比如服务器开发的重点。

我们的架构是从服务器开发中获取的经验，服务器的作用就是能在多个APP中共享数据，提供API访问。我们可以把服务器当做我们的Model，然后把服务器提供的API当做架构中的Command、Query，服务器当然也可以像我们的架构一样，拥有自己的System模块，来统一处理逻辑，本质上是一样的。一般一个服务器包含四层，API层、系统层、模型层、工具层。