某位计算机大师说过:
计算机科学领域任何问题，都可以间接的通过添加一个中间层来解决.什么是架构?
先引用《系统架构：复杂系统的产品设计与开发》里面的一句话：结构良好的创造活动要优于毫无结构的创造活动。
架构始于建筑，是因为人类发展（原始人自给自足住在树上，也就不需要架构），分工协作的需要，将目标系统按某个原则进行切分，切分的原则，是要便于不同的角色进行并行工作。
一般而言，软件系统的架构（Architecture）有两个要素：
.它是一个软件系统从整体到部分的最高层次的划分。
2.一个系统通常是由元件组成的，而这些元件如何形成、相互之间如何发生作用，则是关于这个系统本身结构的重要信息。
详细地说，就是要包括架构元件（ArchitectureComponent）、联结器（Connector）、任务流（TASk-flow）。所谓架构元素，也就是组成系统的核心"砖瓦"，而联结器则描述这些元件之间通讯的路径、通讯的机制、通讯的预期结果，任务流则描述系统如何使用这些元件和联结器完成某一项需求。
建造一个系统所作出的最高层次的、以后难以更改的，商业的和技术的决定。
在建造一个系统之前会有很多的重要决定需要事先作出，而一旦系统开始进行详细设计甚至建造，这些决定就很难更改甚至无法更改。显然，这样的决定必定是有关系统设计成败的最重要决定，必须经过非常慎重的研究和考察。
根据我们
SingleResponsibilityPrinciple :单一职责原则
LiskovSubstitutionPrinciple:里氏替换原则
DependenceInversionPrinciple：依赖倒置原则
InterfaceSegregationPrinciple:接口隔离原则
LawofDemeter
:迪米特法则
OpenClosedPrinciple:开闭原则
软件开发之所以会有这些原则，就是因为复杂多变且不可预料的需求。并不是说在实际项目开发中对这六大原则中的每一条都遵循到极致，而是说在项目开发的过程中，根据项目的实际需求尽量的去遵守这些原则。当然要做到这些肯定是不容易的，能真正做到并且做好的恐怕也只能是有经验之人。
问题场景:
模块独立性指每个模块只完成系统要求的独立子功能，并且与其他模块的联系最少且接口简单，两个定性的度量标准――耦合性和内聚性。
耦合性也称块间联系。指软件系统结构中各模块间相互联系紧密程度的一种度量。模块之间联系越紧密，其耦合性就越强，模块的独立性则越差。模块间耦合高低取决于模块间接口的复杂性、调用的方式及传递的信息。
耦合性分类(低―高)
无直接耦合:
2数据耦合:指两个模块之间有调用关系，传递的是简单的数据值，相当于高级语言的值传递;
3标记耦合:指两个模块之间传递的是数据结构，如高级语言中的数组名、记录名、文件名等这些名字即标记，其实传递的是这个数据结构的地址;
4控制耦合:指一个模块调用另一个模块时，传递的是控制变量（如开关、标志等），被调模块通过该控制变量的值有选择地执行块内某一功能;
5公共耦合:指通过一个公共数据环境相互作用的那些模块间的耦合。公共耦合的复杂程序随耦合模块的个数增加而增加。
6内容耦合:这是最高程度的耦合，也是最差的耦合。当一个模块直接使用另一个模块的内部数据，或通过非正常入口而转入另一个模块内部。
内聚性又称块内联系。指模块的功能强度的度量，即一个模块内部各个元素彼此结合的紧密程度的度量。若一个模块内各元素（语名之间、程序段之间）联系的越紧密，则它的内聚性就越高。
内聚性分类(低―高)
偶然内聚:指一个模块内的各处理元素之间没有任何联系。
2逻辑内聚:指模块内执行几个逻辑上相似的功能，通过参数确定该模块完成哪一个功能。
3时间内聚:把需要同时执行的动作组合在一起形成的模块为时间内聚模块。
4通信内聚:指模块内所有处理元素都在同一个数据结构上操作（有时称之为信息内聚），或者指各处理使用相同的输入数据或者产生相同的输出数据。
5顺序内聚:指一个模块中各个处理元素都密切相关于同一功能且必须顺序执行，前一功能元素输出就是下一功能元素的输入。
6功能内聚:这是最强的内聚，指模块内所有元素共同完成一个功能，缺一不可。与其他模块的耦合是最弱的。
耦合性与内聚性是模块独立性的两个定性标准，将软件系统划分模块时，尽量做到高内聚低耦合，提高模块的独立性，为设计高质量的软件结构奠定基础。
间阶层与重构(IndirectionandRefactoring)某位大师说过:计算机科学中的所有的问题,都可以通过增加一个间阶层来解决.
这位大师好像是DennisDebruler.
间阶层的价值：
允许逻辑共享
分开解释意图和实现：你可以选择每个类和函数的名字，这给了你一个解释自己意图的机会。
隔离变化：通过使用子类来隔离同一对象修改对另一处引用带来变化的风险
封装条件逻辑：使用多态机制将条件逻辑转化为消息机制，这往往能降低代码的重复，增加清晰度并提高弹性.
但是:
大多数重构都为程序引入了更多的间接层
过多的间接层会导致代码的层次太深使代码难以阅读.因此要权衡加入间接层的利弊
理解设计模式
、GOF在书中说：设计模式是对被用来在特定场景下解决一般设计问题的类和相互通信的对象的描述；
设计模式就是不断反省，将软件开发经验抽象积累成解决问题的预案。
2、DennisDeBruler曾说过的一句话：计算机科学是一门相信所有问题都可以通过多一个间接层（indirection）来解决的科学。
技术问题的解决思路是类似的：添加间接层。如：J2EE的分层技术、重构等。
间接层的好处：共享逻辑（重用）、分离意图和实现（提高灵活性）、隔离变化（封装）、解耦等。
但是要记住，间接层应用过于泛滥，则会过犹不及，它会导致简单问题复杂化、跳跃阅读、难以理解等问题，适度的使用间接层，设计模式就是很好的范例。
不过在具体操作上，23种模式中间接层的应用可大可小，无比灵活，注意其应用场景。
3、设计模式中广泛遵循了两条设计原则：面向接口编程，而不是实现；优先使用组合，而不是继承。
下面内容是摘自一篇文章的内容:
分层架构分层是一种常见的根据系统中的角色（职责拆分）和组织代码单元的常规实践。常见的分层结构如下图所示：
CQRSCQS(CommandQuerySeparation，命令查询分离)最早来自于BetrandMeyer（Eiffel语言之父，OCP提出者）提出的概念。其基本思想在于，任何一个对象的方法可以分为两大类：
命令(Command):不返回任何结果(void)，但会改变对象的状态。
查询(Query):返回结果，但是不会改变对象的状态，对系统没有副作用。
六边形架构六边形架构是AlistairCockburn在年提出，解决了传统的分层架构所带来的问题，实际上它也是一种分层架构，只不过不是上下，而是变成了内部和外部（如下图所示）。
六边形架构又称为端口-适配器架构，这个名字更容器理解。六边形架构将系统分为内部（内部六边形）和外部，内部代表了应用的业务逻辑，外部代表应用的驱动逻辑、基础设施或其他应用。
适配器分为两种类型（如下图所示），左侧代表UI的适配器被称为主动适配器（DrivingAdapters），因为是它们发起了对应用的一些操作。而右侧表示和后端工具链接的适配器，被称为被动适配器（DrivenAdapters），因为它们只会对主适配器的操作作出响应。
洋葱圈架构洋葱架构与六边形架构有着相同的思路，它们都通过编写适配器代码将应用核心从对基础设施的