这两天和一朋友讨论这样一个问题：你认为公司的架构怎样，有哪些缺点？
其实在回答这个问题之前，有一些概念需要搞清楚，那就是什么是架构？
目前对于架构还并未有一个统一的标准及定义，所以架构的概念就会因为每个人不同而不同，如果尝试问一百人关于架构的理解，可能有一百个答案。
我开始做基础架构到现在已经有两年时间了，但对架构的理解也并不深，有时感觉无从说起，总觉的是一个无形的东西。下面我就总结下我个人对架构的理解，下面纯属个人理解。
第一：架构分层，这里我将架构分为以下两层：
1：基础架构，这也是由于架构本身的一大特点，具备基础性，它的基础性可以这样理解：通常涉及解决各种关键问题的通用方案，即重用性概念，以及涉及系统设计中影响深远的各种方案决策，影响深远说明一旦确定再次修改的代码往往过大。
示例1：各种中间件，中间件就是对某些组件的一种包装，比如我们的系统在访问数据库是需要同时支持多种类型的数据库，比如SQL SERVER,MYSQL ,ORCAL，等等，为了在各种系统访问数据时形成统一的管理，我们可以编写一个通用化的组件来解决此种问题，达到管理容易，编写简单的目的。
示例2：各种通用服务，例如为所有项目提供分布式缓存系统，所有的项目数据都可以通过它来完成数据的缓存，以加强系统性能。
示例3：面向服务概念SOA的实现，通过SOA可以使复杂的业务系统得到解耦。
示例4：项目的分层，比如分几层，每层的功能，想到之间的关系等。
2：对于全局的组织，全局的结构控制，为特定需求提供特殊解决方案，这类重在设计思维。
示例1：如何将复杂系统化分成N个子系统；
示例2：如何实现系统的非功能性需求，比如并发性，稳定性，可扩展性等等；
示例3：设计方案的选择，评估等。
下面是我对于架构的分层结构图：
第二：架构所关心的问题有哪些,通过这些问题，就会发现架构的概念是如此之大，并非三言两语就能说明白的。
1：全局组织和全局结构
2：数据存取协议
3：各种组件的功能定义
4：软件的物理部署
5：设计方案的选择
6：架构评估与实现
第三：架构都有哪些重要作用
1：它是项目干系人进行交流的手段。它代表了系统公共的最高层次抽象，系统相关的很大部分人员均可将它作为互相理解的基础，以此达成共识；
2：上面说到架构具备基础性，所以具备可传递性与可重性的特点，架构层次上的重用性与代码级的重用性有本质区别，它意味着架构的决策能在相似的需求中出现在多个系统中,体现在决策，而不是实现细节；
3：它是早期设计决策的体现，这些决策比以后的开发，设计以及编码以后期的维护工作重要的多。
第四：需要注意的几个观点，为了更加正确的认识架构，需要正确对待类似下面的观点
1：框架(Framework)，框架在一定程度上容易让人理解为架构，其实框架只是架构内容中的一种，代码级别的组件，不能认为搞搞框架就是架构的全部了。比如我们写的各种是间件，为某种特定需求开发的某种具备特殊功能的组件。
2：写大量的中间件是架构吗？是，但它也只属于架构的一小部分，说的准确点是框架的一部分；
3:SOA算架构吗，当然算，它就是上面我理解的基础架构一部分，但这些均只是架构的冰山一角;
4:某公司成功的架构模式能直接移置到另外一家公司的项目中吗？这个问题不能武断，我认为如果项目类型大致相同，移置的可能性会比较大，否则就需要慎重，比如我们不能将一个C/S架构上的思想直接移到到B/S架构的项目上，它们之间的差距是非常大的,即使勉强移置，也需要非常明确以后需要改进的地方，比如说性能问题，原来的架构所应用的环境对性能要求不高，所以运行良好，但如果不变的移置到互联网项目了，郁闷的事就会出来了。
第五：如何表示软件架构,可以通过非常经典的4+1视图模型来从5个不同的视角来反映系统的整体架构：
1：逻辑视图，主要体现的是系统需求，在逻辑视图中，系统会被抽象成一堆的功能抽象，这些抽象主要是来自需求。功能分解有两个功能，第一：进行功能分析；第二：可以提取不同功能模块中可重用点。
2：进程视图，它主要体现系统中的一些非功能性需求，侧重于系统运行时的特征，例如：系统的性能，稳定性，申缩性，并发性，容错能力，分布式等等。
3：物理视图，它主要考虑的是系统的部署问题，比如部署在什么样的硬件上，解决系统的拓扑结构，通信等问题，比如数据库的备份容灾方案等。
4:开发视图，主要解决系统的组织以及管理，比如如何划分子系统，如何编写要重用性组件等。
5:场景视图，它联系以上四个视图，是系统活动的重要抽象，它用来解决在特定场景上分析一个特定的视图。
下面是它们的关系图
总结：架构是一个大概念，不会有统一的定义，每个公司每个项目都会对架构产生影响，只有根据实际情况出发，才有可能开发出最适合自己公司项目的架构模式。