各模块包含了程序里各种各样的功能，他们有信息需要处理的时候，发布信息通知程序（这是他们的主要职责），下面的QA小节里提到了，模块可以依赖一些DOM工具操作方法，但是不应该和系统的其它模块有依赖，一个模块不应该关注如下内容：
1.哪个对象或者模块订阅了这个模块发布的信息
2.这些对象是客户端对象还是服务器端对象
3.多少对象订阅了你的信息
Facade抽象应用程序的核心，避免各个模块之间直接通信，它从各模块上订阅信息，也负责授权检测，确保每个模块有用自己单独的授权。
Mediator(应用程序核心）使用mediator模式扮演发布/订阅管理器的角色，负责模块管理以及启动/停止模块执行，可以动态加载以及重启有错误的模块。
这个架构的结果是：各模块之间没有依赖，因为松耦合的应用，它们可以很容易地被测试和维护，各模块可以很容易地在其它项目里被重用，也可以在不影响程序的情况下动态添加和删除。
发布Pub/订阅Sub的延伸：自动注册事件（Automatic Event Registration)
关于自动注册事件，需要遵守一定的命名规范，比如如果一个模块发布了一个名字为messageUpdate的事件，那么所有带有messageUpdate方法的模块都会被自动执行。有好处也有利弊，具体实现方式，可以看我另外一篇帖子：jQuery自定义绑定的魔法升级版。
QA
1.有可能不使用facade或者类似的sandbox模式么？
尽管架构的大纲里提出了facade可以实现授权检查的功能，其实完全可能由mediator去做，轻型架构要做的事情其实是几乎一样的，那就是解耦，确保各模块直接和应用程序核心通信是没问题的就行。
2.你提高了模块直接不能有依赖，是否意味着不能依赖任何第三方类库（例如jQuery）。
这其实就是一个两面性的问题，我们上面说到了，一个模块也许有一些子模块，或者基础模块，比如基本的DOM操作工具类等，在这个层面上讲，我们是可以用第三方类库的，但是请确保，我们可以很容易地能否替换掉他们。
3.我喜欢这个架构，并且想开始使用这个架构，有任何代码样本可以参考么？
我打算去搞一份代码样本供大家参考，不过在这之前，你可以参考Andrew Burgees的帖子Writing Modular JavaScript 。
4.如果模块需要和应用程序核心直接通信，是否可行？
技术上来将，没有理由现在模块不能和应用程序核心直接通信，但是对于大多数应用体验来说，还是不要。既然你选择了这个架构，那就要遵守该架构所定义的规则。
致谢
感谢Nicholas Zakas的原始贴，将思想总结在一起,感谢Andree Hansson的technical review,感谢Rebecca Murphey, Justin Meyer, John Hann, Peter Michaux, Paul Irish和Alex Sexton,他们所有的人都提供了和本Session相关的很多资料。
您可能感兴趣的文章: