经典软件架构模式（一）
微核模式
针对代码耦合的问题，软件界进行了大量的理论研究和实践，最后发现：系统的架构设计，是改善耦合的最好方式。架构设计的本质，就是：
- 划分耦合的单位——也就是划分模块。系统应该划分成什么样的模块，代表了设计者对于系统应对的需求的基本理解。一旦能清晰的划分出模块了，其代码耦合就有了最基本的范围。而模块本身也是提示程序员理解系统的基本单位。
2. 规范耦合的形式——代码耦合的形式有很多种，如直接调用、事件响应、消息队列等等，这些形式提供了代码耦合的不同特征。直接调用的代码在静态阅读的时候非常容易理解，而事件响应则提供了运行时耦合的好处。耦合的形式还有另外一层含义，就是代码耦合的规范：那些模块之间应该直接耦合，哪些不能耦合，是否应该加入中间层次等等。
分层模式
下面我们开始第一个架构模式的介绍，先看一个案例：
这是一个有着复杂功能的多人在线社区，其服务器端是我们需要讨论的重点。这个产品的服务器端必须满足多样的功能：玩家移动到不同的场景中，玩家可以换上不同的服装，可以互相加好友并且聊天，同时还有广播频道的聊天，每个玩家还有自己的资料库和背包，另外还有各种运营活动。
在最初的开发过程中，我们针对每个需要开发的功能，建立了一个模块。这些模块通过单独和客户端、数据库的操作，完成所需功能。如果要开发新功能，就重新写一个这样的模块。这种架构设计在一开始是非常有效的，产品功能被不断的开发出来，模块的数量也在增多，但是也潜藏了一个问题。
这个问题的爆发是随着一个叫做“任务系统”的功能而出现的。因为任务系统本质上是需要很多其他模块的功能提供支持。如需要玩家去某个场景（场景模块），获得某个东西（背包模块），然后添加一个好友（好友模块），或者换上某个服装，说一句话等等……这样的任务功能的实现，被迫要修改很多个模块的代码，因为每个模块都只有最基本的“自由使用”功能的代码，编程接口都仅仅是面向客户端的，而数据结果都是直接SQL到数据库的。这种需要组合的功能请求，以及获得功能的结果状况，都是其接口上没有的。这导致了非常复杂的，持续的代码修改。因为任务的内容可是时常会变化的哦！
在分析了问题之后，我们决定重构整个架构，我们把架构从一字排开的设计，修改成为可以多个层次互相调用的模块。这些模块直接的接口，有面向客户端的，也有面向其他模块的，这样我们就能直接调用那些现成的功能，组合开发出更复杂强大的功能。不管任务系统如何变化，我们都可以不用重写那些已经实现的功能，这让整个系统成为可以应对这种需求变化的关键。
实际上，这样的架构正是一个著名的架构模式——分层模式。
分层模式的规定非常简单而有效：
1. 每个模块都必须属于某个层次，提供给“第N+1层”（上层）服务；同时委派任务给“第N-1层”的模块。
2. 任何一个模块，都不得逆层次调用：属于第N层的模块，不得调用（耦合）第N+1层或以上层次的模块。
3. 任何一个模块，都不得跨层调用：属于第N层的模块，不应该调用第N-2层或更下层的模块。
分层模式是架构中最基本的模式，但是也是我们开发中最被忽视的模式。我们开发中往往没有去定义代码的“层次”，仅仅以“功能”纵向划分模块，没有按实现层次横向切分。
门面模式、策略模式都常常用来实现分层架构。
上文所说的例子，后来改造成了分层模型：
1）重复代码减少了，功能开发更快了——一顶层开发只需要学习下层类库，就可以开始开发；近似功能模块被统一，修BUG覆盖面更好。
2）性能提升代码能更好的覆盖了——集中了通用实现代码，也集中了优化部分
3）可以并行开发，资深人员负责底层，一般人员负责上层
总结一下分层模式：
“模式的模式”——强大同时灵活
★ 方法论：以业务逻辑特征建模 ——使用分层模式，往往需要我们在大脑里对问题领域进行层次抽象，这种抽象最可信赖的原则，就是按照业务逻辑去做。比如现实业务中有一个角色，我们就建立一个角色的模块；如果我们有一个场景，就以此为名建立一个这样的模块……。以业务逻辑建立的模块，本身也会让系统更容易被理解，因为在代码里能找到和现实中一一对应的概念。
★ 设计模式实现：
★ 门面模式 ——我们对于每个模块或者每个层次都会设计一个“门面”来降低耦合的复杂程度。
★ 策略模式——抽象层次会隐藏底层的实现细节，这就是策略模式最基本的设计，我们往往会把上层作为功能接口，下层作为可选的策略来实现。
我们来看第二个案例，这是一个多人在线的游戏社区。在这个社区中，除了可以聊天、换衣服之外，还有大量的小型、中型、甚至大型游戏可以玩。这些游戏的内容，都会和整个社区以及角色集合起来，有点像几十个不同的游戏融合成的一个大游戏。
