如果有人让你介绍你们做的系统架构是什么样子的 你会从哪说起？
每个人都会有自己的架构认知，根据自己的接触的内容来总结。系统分为用户中心、营销中心、商品中心…… 这是产品经理说的；我们的系统用了三层架构，用了SSM框架…… 这是程序员说的；用户说 我们系统有后台，前台，商品上下架功能，用户管理功能。
在实际工作中架构师架构出来的系统不仅要考虑用户的功能实现，而且也要平衡系统的易用性、高性能、扩展性、可伸缩性等方面，这里面是要综合业务目标、当前开发人数、开发人员的综合能力、上线时间、项目预算等来选择开发语言、开发框架和功能开发的顺序。有些公司求时间、有些公司求质量，但最终说明架构是实时变化的，不是一上来就来个完美的架构，是要根据当前的业务需求变化的，但你的架构必须要支持这种变化 达到上面所说的要求。
一个复杂的系统需要不同角色的人来参与，因此架构师必须考虑到让不同的参与者理解你的架构 知道他们自己该做什么事，如用户为你提供原始需求，项目经理需要制定计划 在不同小组间沟通 落地你的架构，开发人员拿到你的设计实现功能。所以架构涵盖的内容和决策太多了，需要从不同视角分别设计 ，也是为了架构方便理解、交流和归档的方便。
最常用的架构分为：逻辑架构和物理架构视图 逻辑架构逻辑架构规定了由哪些逻辑元素组成以及这些逻辑元素间的关系，逻辑元素可以是逻辑层、功能子系统、模块。
展示模块间的部署逻辑，数据如何产生、哪块计算、怎么存储、共享等在计算机中的情况。
这里暂时先列出概念，架构设计之初避免涉及太多具体的技术细节，需要看透需求，寻找出实现的难点、以质量还是时间优先。
5视图法：逻辑架构、物理架构、数据架构、开发架构、运行架构面对不同的角色需要用不同的思维来表达，对领导汇报用业务图而不能讲技术架构，对开发则可讲具体开发架构，对运维讲运行架构、物理架构，因此需要不同的架构设计来表达。
逻辑架构逻辑架构= 模块划分+接口定义（统一接口规范）+领域模型
物理架构物理架构=硬件分布+软件部署+方案优化（可伸缩性、高性能、易维护性，监控）
物理架构，更关注的系统、网络、服务器等基础设施。例如：如何通过服务器部署和配置网络环境，来实现应用程序的“可伸缩性、高可用性”。或者举一个实际的例子，如何通过设计基础设施的架构，来保障网站能支持同时10W人在线、7*24小时提供服务，当超过10W人或者低于10W人在线时，可以很方便的调整部署架构来支撑。
数据架构数据架构=存储方式+数据分布
数据架构，更关注的是数据持久化和存储层面的问题，也可能会包括数据的分布、复制、同步等问题。更贴切来讲，如何选择需要的关系型数据库、流行的NOSQL，如何保障数据存储层面的性能、高可用性、灾备等等。很多时候，和物理架构是有紧密联系的，但它更关注数据存储层面的，物理架构更关注整个基础设施部署层面。
开发架构开发架构=技术选型+文件划分+编译关系（模块依赖关系）
开发架构则更关注程序包，不仅仅是我们自己写的程序，还包括应用程序依赖的SDK、第三方类库、中间价等。尤其是像目前主流的Java、.NET等依靠虚拟机的语言和平台，以及主流的基于数据库的应用，都会比较关注。和逻辑架构有紧密的关联。
运行架构运行架构=物理架构+数据流的控制（系统运行中的数据流向关系）
顾名思义，更关注的是应用程序运行中可能出现的一些问题。例如并发带来的问题，比较常见的“线程同步”问题、死锁问题、对象创建和销毁（生命周期管理）问题等等。开发架构，更关注的是飞机起飞之前的一些准备工作，在静止状态下就能规划好做好的，而运行架构，更多考虑的是飞机起飞之后可能发生的一些问题。
实现架构设计的6个步骤： 需求分析