架构，在汉语词典里的意思是：
人们对一个结构内的元素及元素间关系的一种主观映射的产物。
由此可见，万物皆可谈架构。不管是软件、飞机还是建筑，只要人们主观地对其进行分解和组装，就已经运用了架构的概念。
实际上，架构起源于建筑领域。充满智慧的古代劳动人民将复杂的建筑按其特点分解为一个个具有共性的结构构件和建筑构件。仔细想想，楼面、墙体、柱子、地基，和软件工程中的MVC是不是如出一辙？
既然架构是人主观设计的，就必然有好坏之分。
好的架构设计，如赵州桥。虽为石板所铸，屹立千年不倒。
坏的架构设计，如美国的塔科马海峡大桥。耗资近千万美元，却在建成4月后被微风吹塌。
2 架构本质架构的本质是关注点分离。
这种系统思维方法可以追溯到柏拉图时期，与“庖丁解牛”思路相近。具体做法是先将复杂问题做合理的分解，将问题的各个关注点分而治之，再进行组合，最终形成整体的解决方案。
软件架构设计应该按照其业务特点来将软件本身划分成不同的部分，将变化点错落有致地封装到软件系统的不同部分，从而降低耦合性。这样即使面对变化，也能清晰地识别变化点，将影响最小化。
3 架构视图 3.1 企业架构架构视图五花八门，但是是分层的，目前常见的是从企业架构说起。企业架构处于战略层面，是架构的最顶层，自顶向下能更简洁明了地看清各种架构视图间的层次关系。
企业架构（Enterprise Architecture，EA），是基于业务导向和驱动的架构来理解、分析、设计、构建、集成、扩展、运行和管理信息系统。将跨企业的、常为零散的那些遗留流程优化进一个集成的环境，及时响应变更并有效的支持业务战略的交付，辅助企业完成业务及IT战略规划。
主要的企业架构框架为Zachman、EAP、TOGAF、FEA、DoDAF这五种：
其中，最主流的是 TOGAF（开放组体系结构框架）。从TOGAF中，我们能看到再熟悉不过的业务架构、系统架构和技术架构。
业务架构、系统架构和技术架构往往会一同出现，因为他们是一个层面上的概念。
3.2 业务架构业务架构是企业的蓝图，它提供了对组织的共识并用于对齐战略目标和战术要求。关注点在于业务需求，是把企业的业务战略转化为日常运作的渠道。独立于技术而关注业务能力、流程和产品是非常重要的，这是与业务相关的架构视角分析。
业务架构可以分为战略业务架构和运营业务架构，包括业务的组织结构、企业目标和目标、业务功能、商业服务、业务流程、业务角色、业务数据模型、组织和职能的相关性等。设计过程中主要考虑业务平台化、核心业务与非核心业务剥离、主辅流程区分、不同类型业务隔离。
3.3 系统架构系统架构是顺接业务转向IT的重要架构，关注点在于系统的应用和数据架构问题。由应用架构和数据架构构成。
这一阶段需要开发基准和信息系统架构，进行支持已有架构视图的缺口分析，架构信息系统服务，并将它们与业务服务相关联。
系统架构的表现形式通常就是线框图，它的目的是将系统分解成多个独立的子系统，本质上是遵循分而治之的理念。
3.4 技术架构技术架构，关注点在于架构所需的基础设施（例如硬件和通讯）以及平台、中间件。可以粗略地认为技术架构由软件架构与基础架构组成。
技术架构定义了实现系统所需的各种技术，包括开发类、过程管理类、运行环境类、运维支撑类、以及相关技术规范等，描述了应用、应用平台、基础设施等技术组件与信息系统间的关系。
3.5 应用架构应用架构，关注点是IT系统、功能模块的统一规划、架构标准/原则、边界划分和关联关系。
应用架构向上承接了企业战略发展方向和业务模式，向下规划和指导企业各个IT系统的定位和功能。包括了应用系统服务、逻辑应用组件、物理应用组件、应用分布、应用共享、应用集成、应用管理原则等。
3.6 数据架构数据架构，关注点是持久化数据的组织、数据传递、数据转换和数据存储策略。
数据架构，包括业务数据模型、逻辑数据模型、物理数据模型、数据编码规范、数据管理流程模型、数据实体/业务功能矩阵、与选定观点相对应的数据架构视图等。
数据架构解决数据持久化和存储层面的问题，包括数据的分布、复制、同步等。具体表现为确定要存储的数据，可以是文件、关系数据库、实时数据库等；确定存储格式，包括文件格式、数据库图表等；确定需要的数据库；保障数据存储层面的性能、高可用性、灾备等。
3.7 基础架构基础架构，关注点在于系统运行所需的基础设施。
基础架构是指企业IT环境存在、运行和管理所需的硬件、软件、网络资源和服务的组合。它允许组织向其员工、合作伙伴和/或客户提供It解决方案和服务，通常是组织内部的，并部署在自有设施中。
3.8 软件架构软件架构，关注点是软件系统中元件之间的关系。
软件架构是对软件系统运行时元素的抽象，定义和设计软件的模块化，模块之间的交互，用户界面风格，对外接口方法，创新的设计特性，以及高层事物的对象操作、逻辑和流程。可以粗略地认为软件架构由逻辑架构、开发架构、运行架构组成。
3.9 部署架构部署架构，关注点是软件如何部署。举例来说可以将所有的软件模块放在一台WEB服务器上，也可以用微服务的方式部署在不同的服务器上，当然缓存、数据库、文件服务器等都可以独立部署。
从这个角度讲，部署架构是将在逻辑架构上拆分出来的组件（或模块）是如何分解到基础架构不同的物理设备上的。
3.10 逻辑架构逻辑架构，关注点是功能需求，是行为和职责的划分。
逻辑架构包含用户直接可见的功能，还有系统中隐含的功能。并明确其与协作关系；其中职责的划分注意逻辑的分层、子系统以及关键类的定义；协作的定义关注接口的定义与协作关系的明确。
3.11 开发架构开发架构，关注点是程序源代码，配置文件、编译后的目标文件和第三方库文件等软件模块实际组织方式。着重考虑开发期质量属性，包括可扩展性、可重用性、可移植性、易理解性、易测试性。
不仅仅是应用程序本身，还包括应用程序依赖的SDK、第三方类库、中间价等。尤其是像目前主流的Java、.NET等依靠虚拟机的语言和平台，以及主流的基于数据库的应用，和逻辑架构有紧密的关联。
开发架构的目的是确定程序单元以及程序单元的组织结构；其中程序单元包括源文件、配置文件、程序库、框架、目标单元；程序单元组织包括project划分、project目录结构、编译依赖关系。
3.12 运行架构运行架构，关注点是系统的并发和同步，涉及进程和线程等技术。着重考虑运行期质量属性——性能、可伸缩性、持续可用性、安全性。
顾名思义，更关注的是应用程序运行中可能出现的一些问题。例如并发带来的问题，比较常见的“线程同步”问题、死锁问题、对象创建和销毁（生命周期管理）问题等等。开发架构，更关注的是飞机起飞之前的一些准备工作，在静止状态下就能规划好做好的，而运行架构，