High-performance JavaScript websites作者Nicholas,Zakas：
"The key is to acknowledge from the start that you have no idea how this will grow. When you accept that you don't know everything, you begin to design the system defensively. You identify the key areas that may change, which often is very easy when you put a little bit of time into it. For instance, you should expect that any part of the app that communicates with another system will likely change, so you need to abstract that away." -
一大堆文字问题，太麻烦了，总结一句就是，一切皆可变，所以要抽象。
jQuery Fundamentals作者Rebecca Murphey：
各个模块之间联系的越密切，重用性越小，改变起来困难越大。
以上这些重要观点，是构建架构的核心要素，我们需要时刻铭记。
头脑风暴
我们来头脑风暴一下，我们需要一个松耦合的架构，各模块之间没有依赖，各个模块和程序进行通信，然后中间层接管和处理反馈相应的消息。
例如，我们如果有一个JavaScript构建在线面包店程序，一个模块发出了一个信息可能是“有42个圆面包需要派件”。我们使用不同的layer层来处理模块发来的消息，做到如下：
模块不直接访问程序核心
模块不直接调用或影响其它的模块
这将防止我们因为某个模块出错，而导致所有的模块出错。
另外一个问题是安全，真实的情况是，大多数人都不认为内部安全是个问题，我们自己心里说，程序是我自己构建的，我知道哪些是公开的那些私有的，安全没问题，但你有没有办法去定义哪个模块才能权限访问程序核心？例如，有一个chat聊天模块，我不想让他调用admin模块，或者不想让它调用有DB写权限的模块，因为这之间存在很脆弱，很容易导致XSS攻击。每个模块不应该能做所有的事情，但是当前大多数架构里的JavaScript代码都有这种的问题。提供一个中间层来控制，哪个模块可以访问那个授权的部分，也就是说，该模块最多只能做到我们所授权的那部分。
建议的架构
我们本文的重点来了，这次我们提议的架构使用了我们都很熟知的设计模式：module, facade和mediator。
和传统的模型不一样的是，为了解耦各个模块，我们只让模块发布一些event事件，mediator模式可以负责从这些模块上订阅消息message，然后控制通知的response，facade模式用户限制各模块的权限。
以下是我们要注意讲解的部分：
1 设计模式
1.1 模块论
1.1.1 综述
1.1.2 Module模式
1.1.3 对象自面量
1.1.4 CommonJS模块
1.2 Facade模式
1.3 Mediator模式
2 应用到你的架构
2.1 Facade - 核心抽象
2.2 Mediator - 程序核心
2.3 紧密联合运作起来
模块论
大家可能都或多或少地使用了模块化的代码，模块是一个完整的强健程序架构的一部分，每个模块都是为了单独的目的为创建的，回到Gmail，我们来个例子，chat聊天模块看起来是个单独的一部分，其实它是有很多单独的子模块来构成，例如里面的表情模块其实就是单独的子模块，也被用到了发送邮件的窗口上。
另外一个是模块可以动态加载，删除和替换。
在JavaScript里，我们又几种方式来实现模块，大家熟知的是module模式和对象字面量,如果你已经熟悉这些，请忽略此小节，直接跳到CommonJS部分。
Module模式