有角度就有空间。多视图方法背后的核心思想有些类似：从不同角度，规划“分割”与“交互”。
1 软件架构为谁设计？
什么是软件架构？不同的角色有不同的看法。
程序员：软件架构就是决定编写哪些类，使用哪些库和框架。
程序经理：软件架构就是模块的划分和接口的定义。
系统分析员：软件架构就是业务领域对象的关系建模。
配置管理员：软件架构就是开发出来的以及编译过后的软件到底是个啥结构。
DBA：软件架构规定了持久化数据库的结构，其他一切只不过是对数据的操作而已。
运维：软件架构规定了软件部署到硬件的策略。
用户：软件架构应该是将系统划分为一个个功能子系统。
以上，就是从不同的视角得到的不同的软件架构视图。而架构师需要为不同社众的需求而设计。
架构视图的本质是“分而治之”，能帮助架构师从不同角度设计，特别是面对复杂系统时，“分而治之”的设计是必须的。
2 如何设计？
1 为用户设计。
为什么开发一个软件？因为要给用户使用，或者辅助用户完成工作，或者为用户提供娱乐等等。
用户要功能，也要质量，缺一不可。
架构师必须牢记：为用户而设计。
同时，诸如性能，易用性等软件质量属性，并不像“软件功能”那样直接帮助用户达到特定目标，但也非常重要。例如，如果你开发一个查询余额功能，查询一次需要一分钟，虽然能得到结果，但用户肯定无法接受。
因此，架构师必须牢记：为用户设计的同时，不仅要满足用户要求的功能，也要达到用户期望的质量。
2 为客户而设计
很多时候，用户 不等于 客户。
例如，开发一个商场收银系统，很明显，客户是商场老板，用户是商场收银员。
架构师需要为客户而设计：充分考虑客户的业务目标、上线时间的需求，预算限制，以及集成需要等，还要特别关注客户所在领域的业务规则和业务限制。
例如：如果客户是一家小型超市，那么就不应该使用那种需要昂贵的设备和搞性能中间件的架构方案。
3 为开发者设计
开发流程中，一般先研究需求，再设计架构，然后交给开发人员编程......作为架构，不仅要为“上游”的需求而设计，还要为“下游” 的开发人员而设计。
例如，性能是软件运行期间的重要属性，也是重要的的质量属性，最关心性能的人其实是客户；
程序员最关心什么？可扩展性。可扩展性也是软件开发期间的重要质量属性。
不只是可扩展性，还有可重用性，可移植性，易理解性，易测试性等，都是开发人员关心的。
架构师必须牢记：为了使开发流程更顺畅，必须为开发者设计。
4 为管理人员设计
软件越来越复杂，单兵作战已经很少了，取而代之的是团队开发，而团队开发反过来又导致软件开发更加复杂，因此，现在不仅仅是软件复杂的问题，还有管理复杂的问题。
开发人员之间的依赖，源自他们负责的程序之间的依赖，要理清并管理好协作，就应该搞清楚系统一级“模块 + 交互”的设计，搞清楚架构。可见，架构是开发管理的核心基础。
就软件项目管理而言，软件架构应当起到应有的作用：为项目经理指定项目计划、管理项目分工和考核进度等提供依据。
一方面：软件架构应该从大局着手，就技术方面的重大问题作出决策，构造一个由粗粒度模块组成的解决方案，从而把不同模块分配给不同的小组分别开发。
另一方面：软件架构应当规定各个模块如何交互的机制和接口，在开发小组之间，起到“沟通桥梁”和“合作契约” 的作用。
5 小结
架构师在设计架构时，应该要考虑到不同的角色，使架构满足包含了关于如何构建软件的一些最重要的设计决策的定义。
如下图：
3 什么是架构视图
为什么提供多个架构视图？
- 架构要涵盖的内容和决策太多了，超过了人脑“一撮而就” 的能力范围，因此采用“ 分而治之” 的办法从不同视角分别设计。
- 同时，也为了软件架构的理解，交流和归档提供了翻倍。
在多种架构视图中，最常用的是逻辑架构视图和物理架构视图。
1 什么是逻辑架构视图？
软件的逻辑架构视图，规定了软件系统由哪些逻辑元素组成，以及这些逻辑元素之间关系。
软件逻辑架构的核心任务，是比较全面的识别模块，规划接口，并基于此进一步明确模块之间的使用关系和使用机制。通常，一个软件的 UML 类图，就是他的逻辑架构。
2 什么是物理架构视图？
说白了，就是由哪些物理元素组成，以及这些物理元素是如何交互的。
物理架构可以反映出软件系统动态运行时的组织情况，通常物理元素就是进程、线程、类的实例对象等，而进程之间的调度，线程同步，进程/线程通信等，则进一步反映出物理架构的动态行为。
3 如何设计一个 逻辑视图 + 物理视图 的软件架构？
架构设计，将会指导后续的详细设计和编程，而详细设计和编程，这会贯彻和利用这些设计：
a 首先设计逻辑架构，体现为，层、功能子模块和模块等的划分决策，有了模块划分，比如产生协作，逻辑接口还要规定这些模块之间如何进行交互，因此还要设计交互接口。
b 所谓交互，指不同模块之间的沟通和通信，一般有几种方式：方法调用、RPC 远程调用，消息机制。
c 物理架构，关注软件在运行时期的情况，物理架构规定了软件系统如何利用进程和线程完成期望的并发处理，进程线程这些主动单元会调用哪些被动单元，消息直接的交互如何处理等等。这些设计，将会为后续编程实现提供基础。
具体过程如下图：
4 架构设计流程实战
设计技巧：
先有需求，再有用例，通过分而治之和迭代式设计，设计第一版本的逻辑视图，有了逻辑视图，再设计第一版本的物理视图，再根据第一版本的物理视图设计 第二版本的逻辑视图
1 用例设计（需求设计）
2 逻辑架构设计版本 1
3 物理架构设计版本 1
4 逻辑结构设计版本 2
5 物理架构设计版本 2
6 逻辑架构设计版本 n.....
7 逻辑架构设计版本 n.....
假设我们现在有个需求：设计一个邮件代理服务器，并且提供后台管理功能。
根据上面的流程, 先来个用例图：
逻辑视图 版本 1
物理视图 版本 1
逻辑视图 版本 2
物理视图 版本 2
到这里，我们就基本完成了一个 逻辑视图 + 物理视图的 架构设计。
我们通过分而治之，迭代式设计的方式，让逻辑架构设计和物理架构设计交替进行，不断验证，促进设计优化，从而完成架构设计。
参考
软件架构设计——温昱