在实际开发工作中。我们经常听到“架构设计”和“架构师”这种名词，它并不新奇和神奇，可是却非常少有人对“架构”有全面的了解和认识。更谈不上掌握了。事实上，也仅仅有极少数人能成为或者被冠以“架构师”这种title。为此。笔者总结了实践中对架构的一些理解，希望能够补充非常多人对此认识上的不足，纠正一些误解。
对于“架构”来讲。理论上划分了5种架构视图，各自是：逻辑架构、开发架构、执行架构、物理架构、数据架构。
依据名字。大家都可能大概能猜到其側重点和含义。
这里先用通俗的文字简介下。便于大家理解，大家能够不必纠结概念和这些理论。我们一般会重点关注“逻辑架构”和“物理架构”。
逻辑架构：逻辑架构关注的是功能，包含用户直接可见的功能，还有系统中隐含的功能。或者更加通俗来描写叙述，逻辑架构更偏向我们日常所理解的“分层”，把一个项目分为“表示层、业务逻辑层、数据訪问层”这样经典的“三层架构”。
开发架构：开发架构则更关注程序包。不仅仅是我们自己写的程序，还包含应用程序依赖的SDK、第三方类库、中间价等。尤其是像眼下主流的Java、.NET等依靠虚拟机的语言和平台，以及主流的基于数据库的应用，都会比較关注。和逻辑架构有紧密的关联。
执行架构：顾名思义。更关注的是应用程序执行中可能出现的一些问题。比如并发带来的问题，比較常见的“线程同步”问题、死锁问题、对象创建和销毁（生命周期管理）问题等等。开发架构。更关注的是飞机起飞之前的一些准备工作。在精巧状态下就能规划好做好的。而执行架构，很多其他考虑的是飞机起飞之后可能发生的一些问题。
物理架构：物理架构，更关注的系统、网络、server等基础设施。比如：怎样通过server部署和配置网络环境，来实现应用程序的“可伸缩性、高可用性”。或者举一个实际的样例。怎样通过设计基础设施的架构。来保障站点能支持同一时候10W人在线、7*24小时提供服务，当超过10W人或者低于10W人在线时，能够非常方便的调整部署架构来支撑。
数据架构：数据架构，更关注的是数据持久化和存储层面的问题，也可能会包含数据的分布、复制、同步等问题。
更贴切来讲，怎样选择须要的关系型数据库、流行的NOSQL，怎样保障数据存储层面的性能、高可用性、灾备等等。
非常多时候。和物理架构是有紧密联系的，但它更关注数据存储层面的。物理架构更关注整个基础设施部署层面。
上面讲了那么多。相信国内非常少有公司是严格依照这五种视图去分工和设计的。
事实上在笔者眼中，架构大致分为两种：软件架构、系统架构。前三种视图。能够归纳为软件架构。而后两种架构，则归为系统架构。这也比較符合国内大部分中小型互联网公司的分工和布局。
依据应用特性的不同，关注側重点可能不同。比如，某些门户类的互联网应用，读多写少并且业务相对照较简单，则更加关注“高性能、可伸缩性、可用性”等方面。对于更加复杂的应用。比如电商这类大规模交易型的应用，对每一个层面和每一个环节都会比較关注。
对于业务型的系统。比如一些生产型企业使用的ERP，或者仅供企业内部使用的一些MIS、OA应用，通常更关注功能和复杂的业务和实现、扩展。而非常少会对性能等方面又太多要求。这类应用则更关注纯软件架构层面。这里，不展开做详细讨论。
在长期的技术招聘面试中，我发如今非常多人眼中。架构就是分层，架构设计就是“三层架构”（或者四层、五层...反正分层越多就说明项目越复杂并且架构就越牛），
也许是受到诸如PetShop之类的演示样例项目的影响，这里临时不去追究原因了，先纠正非常多人的一些误解吧。
先说一下笔者的理解：
架构就、是有用并且优雅的设计，它不在于分多少层。或者应用了多少种设计模式/架构模式。它应该是以满足实现用户需求为前提，以开发者普遍可接受为根本的，并且要符合系统特性和业务发展须要的，从软件设计的角度，能够达到层次和结构清晰、可维护、可重用、可扩展...就非常优秀了，无需刻意去纠结分了多少层，是否使用了什么模式等。以面向对象为例，基本目标是“高内聚、低耦合”。为此我们可能会遵循一些常见的设计原则（比如经典的SOLID设计原则）。最后纠正一点，通常我们所说的模式，事实上又分为非常多种。并非仅仅指的是“设计模式”。它通常包含：企业架构模式、设计模式、SOA模式、企业集成模式等等。
强调一下。架构要讲求“有用”。并且开发者普遍可接受。否则再“优雅”的设计，都会沦为高成本的“花架子”，生搬硬套仅仅会让项目“流产”。
笔者曾多次在一些技术社区和论坛看到一些关于Tier和Layer的争论。众说纷纭。
事实上最easy被广泛认可和接受的理解就是：Tier通常指的是物理上的分层，由执行相同功能的一台（或者一组）server定义。而Layer通常指的是逻辑上的分层，对于代码的组织，比如：我们通常提到的“业务逻辑层。表现层，数据訪问层”等等。
Tier指代码执行的位置，多个Layer能够执行在同一个Tier上的。不同的Layer也能够执行在不同的Tier上，当然，前提是应用程序本身支持这种架构。
以J2EE和.NET平台为例，大多数时候，不同的Layer之间都是直接通过DLL或者JAR包引用来完毕调用的（比如：业务逻辑层须要引用数据訪问层），这样部署的时候，也仅仅能将多个Layer同一时候部署在一台server上。
相反，不同的Layer之间假设是通过RPC的方式来实现通信调用的，部署的时候。便能够将不同的Layer部署在不同的server上面，这也是非经常见的解耦设计。
例如以下图所看到的：
逻辑分层的优点：
- 代码组织更清晰
- 更易于维护
- 更好的代码重用性
- 更好的团队开发体验性
- 更高的代码清晰度
物理分层的优点：
架构师往往是非常多开发者向往的职业。它并不神奇，也不是像非常多人想象中的那样（画一下PPT或者UML草图，然后交给程序猿们去实现，然后自己就自由了）。国内非常多公司。是没有架构师这种岗位定义的。一般是由技术优秀和经验比較丰富的开发者担任，身兼多职的情况也并不少见（非常多人是身兼主管、系统分析师、项目经理、架构师、核心开发者...）。值得纠正的就是，架构师和系统分析师不同，系统分析师更側重在项目早期的需求分析。而架构师，一般贯穿整个软件开发周期。与项目经理也是相辅相成的。
微软对于架构师。又分为：软件架构师、系统架构师、解决方式架构师、企业架构师等。而其他一些厂商，可能又会划分:技术架构师、业务架构师、网络架构师、安全架构师、SOA架构师......大家不必对这些概念太纠结。
依照笔者的理解，国内大互联网公司里。架构师一般仅仅会分2-3个方向：软件架构师和系统架构师（有些企业叫运维架构师），有些企业对于比較资深DBA并且懂整个系统架构的，还会分出所谓的“数据架构师”。至于详细Title。大可不必纠结。仅仅需在知晓了大致发展定位。然后朝该方向努力就可以。
对于程序猿而言，先写出高质量代码，在实战中逐步提升自己设计思维就可以。
本文转自mfrbuaa博客园博客，原文链接：http://www.cnblogs.com/mfrbuaa/p/5066235.html，如需转载请自行联系原作者
