做了好几年架构设计的事了，一直没有好好的总结。实在不好，花点时间总结一下，写出来，有兴趣的朋友可以一起探讨。
软件架构设计的主题狠深狠难，本文打算从架构的概念，架构的表述方法，架构设计的过程三个方面来讲一下我的理解。
一、什么是软件架构？
温昱在《软件架构设计》一书中，给了下面的定义：
组合派：软件系统的架构将系统描述为计算组件及组件之间的交互。
决策派：架构是一系列重要决策的集合，这些决策与以下内容有关：软件的组织，构成系统的结构元素及其接口的选择，这些元素在相互协作中明确表现出的行为，这些结构元素和行为元素进一步组合所构成的更大规模的子系统，以及指导这一组织--包括这些元素及其接口、它们的协作和它们的组合--架构风格。
在我看来，决策派的定义更为具体和准确，注意决策派用了元素这一词而没有用组件，组件是有具体含义的，指一个可独立替换的物理单元，而架构需要能够指导涉众，如开发人员、用户、部署人员等等，对开发人员来讲，开发过程中如何分包、如何将包打包为组件，架构师需不需要提供指导呢，答案是肯定的。因此，如果将架构限定在组件和组件的交互上，是不完整的。
二、架构的表述方法
这个现在都有共识，就是4+1视图表述法：逻辑视图，实现视图，进程视图，部署视图，用例视图。 参见下图RUP 4+1视图：
用例视图关注系统的人、事、物、规则，人是指系统的Actor，包括业务主角和业务工人，事是指系统用例，物是指业务实体，规则指做事情的前置条件、后置条件，做事情过程中的规则。下面这个图很精辟：
用例视图是4+1视图中的+1，它定义需求标准，跟其它视图描述系统某一方面的结构有很大的不同。
逻辑视图关注系统的逻辑功能模块和领域模型，不仅包括用户可见的功能模块，还包括实现用户功能而必须提供的“辅助功能模块”；它们可能是逻辑层、功能模块、类等。
实现视图关注程序包，不仅包括要编写的源程序，还包括可以直接使用的第三方SDK和现成框架、类库，以及开发的系统将运行于其上的系统软件或中间件。开发架构和逻辑架构之间可能存在一定的映射关系：比如逻辑架构中的逻辑层一般会映射到实现架构中的多个程序包；再比如实现架构中的源码文件可以包含逻辑架构中的一到多个类（在C++里一个源码文件可以包含多个类，即使在Java里一个源码文件也可以同时包含一个类和几个内部类）。
进程视图关注进程、线程、对象等运行时概念，以及相关的并发、同步、通信等问题。
进程视图和实现视图的关系：实现视图一般偏重程序包在编译时期的静态依赖关系，而这些程序运行起来之后会表现为对象、线程、进程，进程视图比较关注的是这些运行时单元的交互问题。
物理视图关注“目标程序及其依赖的运行库和系统软件”最终如何安装或部署到物理机器，以及如何部署机器和网络来配合软件系统的可靠性、可伸缩性等要求。物理架构和运行架构的关系：运行架构特别关注目标程序的动态执行情况，而物理架构重视目标程序的静态位置问题；物理架构还要考虑软件系统和包括硬件在内的整个IT系统之间是如何相互影响的。
上面几个视图是最典型的视图，不管你是通信中间件，还是依赖于数据库的企业应用都需要的。对于依赖数据库的企业应用，通常还需要数据视图，数据视图关注对象如何存储，如数据库表等。
4+1视图不仅仅是软件架构的表述方法，它们各自从不同的视角去展现架构，因此，还是一种比较好的思维方式，引导我们从不同的视角去思考，从而做出比较系统的架构设计。