本文为《架构漫谈》系列第一篇。本文将会从：”什么是架构”，“架构能解决什么问题”，“架构和框架的区别”三个点来着重讨论,本文系个人观点,如有不正确的地方,欢迎指正讨论。

什么是架构？

　　每当我们开发新的项目的时候都会新建一个解决方案,然后在解决方案中搭建N个项目。每个项目之间通过“引用”达到交互的功能,这个过程就可以称之架构,而架构最终的产物则是软件产品。不同的程序员在搭建架构的时候分两种情况：熟悉业务,根据业务进行架构、不熟悉业务,根据自己的理解进行架构。这两种情况在软件工程行业中有两个名词进行描述，分别是“隐式架构”和“显式架构”。

　　举个例子,让一个经验丰富的程序员去开发一个Blog系统,经验丰富的程序员的脑中就会有一个Blog系统的大体架构,比如功能等等。。反之,如果让一个新手去开发一个Blog系统,那么他可能因为不了解需求、功能等问题需要耽搁很久，所以这时候就需要我们把架构给展现出来,通过草图或UML告诉程序员有哪些功能模块,以及它们之间的关联等等来帮助程序员开发。

　　架构不能脱其需实现的系统而存在。在进行软件架构之前,我们需要理解系统是如何和外部环境发生关系的以及如何嵌入到外部环境中的。架构是一个系统最为核心的部分,是构造系统过程中的支柱。在进行系统架构前,我们往往需要了解很多方面的东西。例如：分析需求、设计系统、根据其技术语言的本身来确保架构的可行性。

　　完美的设计不是包罗万向无所不在,而是完整自洽不可精简。

架构能解决什么问题

　　这个问题可以用一句话来回答：架构是为了解决系统的复杂性,也同时保证了系统的可维护性。

　　一旦进入开发阶段,在架构中我们所定义的一些功能则不能被轻易改变。这里仅仅是指不会轻易改变而不是不能改变。而一些功能可以会随着的业务的变更发生更改，但有了架构之后,我们改起来非常容易。举个例子,某公司需要开发一个金融系统,在开发系统前没有专业的人员进行架构,招了一些程序员分完工就开始写功能。这些程序员在写某一个功能点时根本不会去考虑这个功能别人有没有写过,直接就开始写,殊不知他们写的这个功能已经有几个人都写了。而这时,BOSS说某个功能需要修改,那么这些重复的"轮子"都要跟着修改,如果某位程序员忘记了修改则会导致系统的崩溃。再或者,当时写这个金融系统的程序员如果全部辞职,公司在招人来继续开发这个项目,由于没有整体的架构图可能会导致这个项目无法继续维护下去,最终可能导致项目失败。

架构和框架的区别

　　很多人都会把框架和架构混为一谈,其实不然。框架是软件,而架构不是软件。

　　框架是一种特殊的软件，它并不能提供完整无缺的解决方案，而是为你构建解决方案提供良好的基础。框架是半成品。典型地，框架是系统或子系统的半成品；框架中的服务尅被最终应用系统直接调用，而框架中的扩展点是供应用开发人员定制的“可变化点”。

架构不是软件，而是关于软件如何设计的重要策略。软件架构决策设计到如何将软件系统分解成不同的部分、各部分之间的静态结构关系和动态交互关系等。经过完整的开发过程之后，这些架构决策将体现在最终开发出的软件系统中；当然，引入软件架构之后，整个开发过程变成了“分两步走”，而架构决策往往会体现在框架之中。或许，人们常把架构和框架混为一谈的原因就在于此吧！我们不能指着某些代码，说这就是软件架构，因为软件架构是比具体代码高一个抽象层次的概念。架构势必被代码所体现和遵循，但任何一段具体的代码都代表不了架构。

框架技术和架构技术的出现，都是为了解决软件系统日益复杂所带来的困难而采取“分而治之”思维的结果-----先大局后局部，就出现了架构；先通用后专用，就出现了框架。下图很好地揭示了这一点。架构是问题的抽象解决方案，它关注大局而忽略细节；而框架是通用半成品，还必须根据具体需求进一步定制开发才能变成应用系统。