如果有人让你介绍你们做的系统架构是什么样子的 你会从哪说起？

　　每个人都会有自己的架构认知，根据自己的接触的内容来总结。系统分为用户中心、营销中心、商品中心…… 这是产品经理说的；我们的系统用了三层架构，用了SSM框架…… 这是程序员说的；用户说 我们系统有后台，前台，商品上下架功能，用户管理功能。

　　在实际工作中架构师架构出来的系统不仅要考虑用户的功能实现，而且也要平衡系统的易用性、高性能、扩展性、可伸缩性等方面，这里面是要综合业务目标、当前开发人数、开发人员的综合能力、上线时间、项目预算等来选择开发语言、开发框架和功能开发的顺序。有些公司求时间、有些公司求质量，但最终说明架构是实时变化的，不是一上来就来个完美的架构，是要根据当前的业务需求变化的，但你的架构必须要支持这种变化 达到上面所说的要求。

　　一个复杂的系统需要不同角色的人来参与，因此架构师必须考虑到让不同的参与者理解你的架构 知道他们自己该做什么事，如用户为你提供原始需求，项目经理需要制定计划 在不同小组间沟通 落地你的架构，开发人员拿到你的设计实现功能。所以架构涵盖的内容和决策太多了，需要从不同视角分别设计 ，也是为了架构方便理解、交流和归档的方便。

　最常用的架构分为：逻辑架构和物理架构视图

　　逻辑架构

　　逻辑架构规定了由哪些逻辑元素组成以及这些逻辑元素间的关系，逻辑元素可以是逻辑层、功能子系统、模块。

　　物理架构

　　展示模块间的部署逻辑，数据如何产生、哪块计算、怎么存储、共享等在计算机中的情况。

 这里暂时先列出概念，架构设计之初避免涉及太多具体的技术细节，需要看透需求，寻找出实现的难点、以质量还是时间优先。

5视图法：逻辑架构、物理架构、数据架构、开发架构、运行架构

　　面对不同的角色需要用不同的思维来表达，对领导汇报用业务图而不能讲技术架构，对开发则可讲具体开发架构，对运维讲运行架构、物理架构，因此需要不同的架构设计来表达。

逻辑架构

逻辑架构= 模块划分+接口定义（统一接口规范）+领域模型

物理架构

物理架构=硬件分布+软件部署+方案优化（可伸缩性、高性能、易维护性，监控）

物理架构，更关注的系统、网络、服务器等基础设施。例如：如何通过服务器部署和配置网络环境，来实现应用程序的“可伸缩性、高可用性”。或者举一个实际的例子，如何通过设计基础设施的架构，来保障网站能支持同时10W人在线、7*24小时提供服务，当超过10W人或者低于10W人在线时，可以很方便的调整部署架构来支撑。

数据架构

数据架构=存储方式+数据分布

数据架构，更关注的是数据持久化和存储层面的问题，也可能会包括数据的分布、复制、同步等问题。更贴切来讲，如何选择需要的关系型数据库、流行的NOSQL，如何保障数据存储层面的性能、高可用性、灾备等等。很多时候，和物理架构是有紧密联系的，但它更关注数据存储层面的，物理架构更关注整个基础设施部署层面。

开发架构

开发架构=技术选型+文件划分+编译关系（模块依赖关系）

开发架构则更关注程序包，不仅仅是我们自己写的程序，还包括应用程序依赖的SDK、第三方类库、中间价等。尤其是像目前主流的Java、.NET等依靠虚拟机的语言和平台，以及主流的基于数据库的应用，都会比较关注。和逻辑架构有紧密的关联。

运行架构

运行架构=物理架构+数据流的控制（系统运行中的数据流向关系）

顾名思义，更关注的是应用程序运行中可能出现的一些问题。例如并发带来的问题，比较常见的“线程同步”问题、死锁问题、对象创建和销毁（生命周期管理）问题等等。开发架构，更关注的是飞机起飞之前的一些准备工作，在静止状态下就能规划好做好的，而运行架构，更多考虑的是飞机起飞之后可能发生的一些问题。

实现架构设计的6个步骤：

需求分析

　　根据系统使用人、客户等收集而来的业务实现的背景要求组成的原始需求文档分析，包括了功能要求、质量（性能要求）、约束（时间、预算、可行性分析、风险评估、是否需要对接三方）。这里要输出一份整理过后的需求文档，包含了要做什么（功能范围、非功能性需求），能不能做，能做到的前提要求和要面临的问题，怎么做（进入系统分析实现阶段）。

确定关键需求

       不仅要对功能需求（如用例）进行筛选，还要对非功能需求进行权衡，最终确定对架构起关键作用的需求。如需求是以高性能并发度为关键还是以可扩展性为要求或同时满足，因为考虑到成本、上线时间和现有系统的影响会舍弃一部分需求，需要确定关键需求：核心功能、高风险功能。

概念架构设计

 　　1个决定4个选型：决定如何划分顶级子系统；架构风格选型（C/S还是B/S架构）；开发技术选型（java）；集成技术选型（API）；二次开发技术选型（API）。

细化架构设计

 　　5视图法：分别从逻辑架构、物理架构、数据架构、开发架构、运行架构进行设计，每一块的关注点不一样，可细化粗粒度。

领域建模

　　领域建模的精髓是 业务决定功能，功能决定模型。将需求业务转化为抽象的模型对象之间的流转关系。

　　常用的表达方式是类图 表达模型之间的关系，听得最多的是“建模”。模型的建立也是逐步完善的，还包含了状态（流程图）、特性要求等文字说明。

关于如何领域建模 有专门的 领域驱动设计 方面的书可以参考。

架构验证

 　　可快速开发一个统一框架（一个原型、一个技术难点）来贯彻架构的设计，再对原型进行测试评审 再对架构进行补充。 

　　最后可以总结为可以用5视图法从各方面来描述系统的架构，然后用6步骤来描述怎么实现架构。不过现在还流行一种就是将业务逻辑与物理架构放一起 忽略其中的实现细节。 

　　软件架构就是实用而且优雅的设计，它不在于分多少层，或者应用了多少种设计模式/架构模式等。它应该是以满足实现用户需求为前提，以开发人员普遍可接受为根本的，而且要符合系统特性和业务发展需要的，从软件设计的角度，能够达到层次清晰、可维护、可重用、可扩展…就非常优秀了，无需刻意去纠结分了多少层，是否使用了什么模式，有多么抽象等。以面向对象设计为例，基本目标是“高内聚、低耦合”，为此我们可能会遵循一些常见的设计原则（例如经典的SOLID设计原则）。

　　通常我们所说的模式，其实又分为很多种，并不是仅仅指的是“设计模式”（设计模式也有千千万，并不是只有常见的GOF 23种设计模式）。通常包括：企业架构模式、设计模式、SOA模式、企业集成模式等等。
强调一下，架构要讲求“实用”，而且开发人员普遍可接受，要符合现状的。否则，再“优雅”的设计，都会沦为高成本的“花架子”，生搬硬套和过度设计只会让项目“流产”。