五视图法
它们是：逻辑架构、物理架构、数据架构、开发架构、运行架构
面对不同的角色需要用不同的思维来表达，对领导汇报用业务图而不能讲技术架构，对开发则可讲具体开发架构，对运维讲运行架构、物理架构，因此需要不同的架构设计来表达。
逻辑架构
逻辑架构 = 模块划分+接口定义（统一接口规范）+领域模型
物理架构
物理架构 = 硬件分布+软件部署+方案优化（可伸缩性、高性能、易维护性，监控）
物理架构，更关注的系统、网络、服务器等基础设施。例如：如何通过服务器部署和配置网络环境，来实现应用程序的“可伸缩性、高可用性”。或者举一个实际的例子，如何通过设计基础设施的架构，来保障网站能支持同时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模式、企业集成模式等等。
强调一下，架构要讲求“实用”，而且开发人员普遍可接受，要符合现状的。否则，再“优雅”的设计，都会沦为高成本的“花架子”，生搬硬套和过度设计只会让项目“流产”。
