开发者常常把DOM操作紧密地绑定在应用里，但就算使用模块化把代码分离封装起来，对长远维护一个应用来说，还是不好，因为有一点必须要考虑的：

　　你可能会因为性能、安全或设计的考虑，打算从 Dojo, jQuery, Zepto 或 YUI 换成其他的框架。因为更换框架并不容易，这会导致需要高的转换成本。

　　如果你是一名Dojo开发者，也许现在没有更好的转换目标(框架)，但谁能预料将来就不会出现呢？

　　对小型项目来说，可能不切实际，但对大型项目，自由地使用任何框架或库，从金钱或时间成本来说，是由极大的好处。检查你现在的架构，可能轻易转换框架而不用重写整个应用吗？

　　有一些具有影响力的Java开发者都有提到我说的一些观念，在此我列出三个：

“打造大型应用的诀窍不是在打造一型应用，而是将你的应用拆解成许多小的组件，然后再把他们组成你的应用。” — Justin Meyer, author JavaMVC

“因为刚开始就无法预知这个应用未来的发展趋势，所以就坦然接受在不知道任合条件的情況下，开始你的设计。这个时候你就会花时间在考虑某些关键模块是否会在将来更变上。例如，当一个应用的某个通讯模块在未来有可能会改变与其他系统通讯的方式时，你就会想要做抽象化来适应设计的变更。” — Nicholas Zakas, author ‘High-performance Java websites’

　　最后但并不重要：

　　“组件之间的耦合性很高，其可重用性便低，而且很难再设计变更后却不影响到其他组件的运行。” — Rebecca Murphey, author of jQuery Fundamentals.

　　这些原则对打造大型应用是很有必要而且经得起时间的考虑，需要谨记在心。

　　想想我们新的架构要有什么

　　我们想要一个低耦合的架构，它所包含的功能可以被拆解成许多独立的模块，而且不互相依赖着。模块间的通讯靠的是一个中间层来做信息的交换，比如我们有个线上面包店的应用，一条消息从某个模块发出来：“第42批面包已经做好准备开卖”，这时中间层就负责把这个消息转发给有兴趣的模块。

　　中间层会解析模块发出来的消息，好让a)模块不能直接访问核心功能，和b）模块不用直接呼叫或调用其他的模块。这避免模块发生错误时而导致整个应用失效，并且提供一个机会可以重新启动失效的模块。

　　另一层考虑的是安全性。一般来说，atv，我们很少考虑应用内的安全性，我们认为只要控制好来自应用外部的访问权限就够了。其实不是，如果我不限制一个公开的聊天组件和写资料模块的访问权限，有些人便会利用组件的漏洞进行攻击，所以模块不应该可以访问任何东西，设计一个中间层来处理模块之间的访问权限会增加应用的安全性。

　　提倡新的架构

　　我们提出的新架构是由三个著名的设计模式组成：module，facade和mediator。

　　在传统的模块化架构下，模块之间是直接互相通讯的，但在这新的架构下，它们只会发出事件通知（理想上，不需要知道系统内其他模块的存在）。

　　Mediator模式时用来处理模块间的消息发布和订阅工作，而Facade模式是用来加强模块间的访问权限。

　　接下来我将针对每个模式做详细说明：

　　设计模式

Module Theory

Module Pattern

Object Literan Notation

CommonJS Modules

Facade Pattern

Mediator Pattern

　　应用到你的架构中

The Facade — Abstraction Of The Core

The Mediator — The Application Core

Tying It All Together

Module Theory

　　你可能已经在你现有项目架构下使用模块化，如果没有，这小节会做简单的说明。

　　模块是组成强健应用的基础，每个模块的运行都只是单一的目的，而且还可以被替换。

　　模块的依赖性可以透过自动化的加载来完成，不需要手动，是考虑到扩展性。在粒度上能自行运行的模块就尽量独立出来，就像Gmail的例子，由一个处理表情图片的模块可以被聊天模块或消息模块所引用。

　　在架构里，一个模块是不需要知道其他模块在做什么，这个沟通的工作交由mediator来完成。模块只要让mediator知道现在发生了什么事件，剩下的就让mediator去通知其他对这个事件感兴趣的模块，直播，也因此这种低耦合的设计，当某模块失去功能时，无需担心其他模块会受到影响。

　　在Java中，有几种方式可以当作模块，像是module pattern 和object literals。如果你知道理解这部分，请直接跳到 CommonJS modules。

　　The Module Pattern