系统架构：指的完整系统的组成架构，例如系统分成几个部分？服务平台、管理门户、终端门户、ATM门户、外部系统以及接口、支撑系统等，将这些系统进行合理的划分。然后再进行功能分类细分，例如服务平台内部划分为系统管理、用户管理、帐号管理、支付管理、接口层、统计分析等逻辑功能。总之，将整个系统业务分解为逻辑功能模块，并且科学合理，就是系统架构了。

技术架构：从技术层面描述，主要是分层模型，例如持久层、数据层、逻辑层、应用层、表现层等，然后每层使用什么技术框架，例如Spring、hibernate、ioc、MVC、成熟的类库、中间件、WebService等，分别说明，要求这些技术能够将整个系统的主要实现概括。

应用架构：主要考虑部署，例如你不同的应用如何分别部署，如何支持灵活扩展、大并发量、安全性等，需要画出物理网络部署图。按照应用进行划分的话，还需要考虑是否支持分布式SOA。


-----------------------------------------------------------------------------

架构设计文档如何编写[url]http://lizhengfa.iteye.com/blog/574209[/url]

4+1视图与UML

软件架构设计已经逐渐成为现代软件开发过程的核心，然而能够清晰表明架构设计并不是一件容易的事，就面向对象开发而言，RUP 的4+1视图已在架构设计的撰写中得到了广泛的应用和认可。

对于4+1 view的描述有几个不同版本（或包含的视图不同，或视图的名称不同），文中以Philippe Kruchten, November 1995提出的4+1视图为准。

4+1视图包括：逻辑视图（Logic View），开发视图（Develop View），进程视图（Process View），物理视图（Physical View）和场景视图（Scenarios）。

4+1视图不仅便于我们记录架构设计，实际上它也指导了我们进行架构设计活动的部分过程。

通常我们选择UML来表现各种视图，以下列出了UML和各视图的对应关系

4+1视图 UML

场景视图 use case

逻辑视图 类图

开发视图 类图，组件图

进程视图 无完全对应

部署视图 部署图

在架构设计稳定中通常不会给出较多的用例描述，这些是在需求稳定中定义。但是往往架构文档会选择一些用例，列入文档中，这些用例和一些非功能性需求一起用以证明架构的有效和正确性。在逻辑视图中用例的实现是必不可少的一节，尽管架构设计更关注非功能性需求。

融入MDA的思想

对于逻辑视图和开发视图所应包含的内容常常会觉得很难区分两者间的明显界限。逻辑视图包含更多的分析模型与实现技术本身相关性应该较少，如业务对象模型及其扩展。而开发视图则会与实现技术紧密相关。

随着MDA思想的推广，在架构设计文档的撰写方面也产生了影响，我们不难把MDA的PIM和逻辑视图联系起来，而把MDA中的PSM和开发视图联系起来。

在编写逻辑视图是我们应该描述与技术平台无关的模型，而开发视图则描述与实现技术平台相关的模型。

如在逻辑视图中表现的某些实体类，我们会在开发视图中转换为EJB组件（实体Bean）。

这种做法不仅有利于我们编写架构设计文档，同时更是一种好的架构设计思考流程。

--------------------------------------------------------------------------------

架构设计文档中的各元素评级
几乎所有的文章都认为架构设计很重要，架构师成为程序员系列岗位的顶级岗位。
但是现在的书本和培训并没有给出架构师工作的现成答案，和一些行家交流，会得到一些莫测高深的回答。
如果某个事情在短时间内给讲清楚了，岂不是没有显出讲解者高深水平。

这里希望来简化下架构设计，来说说架构设计的文档所要展现的元素。
架构设计的文档是架构设计的成果物。其中所要展现的元素就是架构设计的成果。从这个角度，也许可以简化下架构设计。
按照Just enough的原则，对于架构设计的元素，最有必要的给5颗星，其次4，3，2，没有必要的、可有可无的给1颗星。

支持的操作系统，比如 win7, Redhat9 ☆☆☆☆☆
支持的数据库 比如Oracle, DB2, Mysql ☆☆☆☆☆
支持的浏览器（如果是有Brower访问的）☆☆☆☆☆
依赖的运行时环境 --比如Java, Silverlight ☆☆☆☆☆
依赖的中间件--- 比如Java容器，tomcat, websphere, Tuxedo ☆☆☆☆☆
依赖的核心构件或者Frame, 比如struts, hibernate, 自定义的构件 ☆☆☆☆☆
层次划分，比如 典型三层架构、多层架构 ☆☆☆☆
识别进程，画部署图 ☆☆☆☆☆
划分组件，画组件图 ☆☆☆☆☆
开发语言 比如c#, java, c++ ☆☆☆☆☆
开发所用的工具 比如IDE，报表设计器 ☆☆☆☆
重要组件间的接口 ☆☆☆☆
核心类的设计 ☆☆☆
数据库设计 ☆☆☆ 存储数据和检索有其特点。在表达方面有其自身的特点。如数据集的提取，运算等, 要注意性能，完整性等。数据库设计也可做渐进设计
核心流程的说明 ☆☆
部分核心类的类图 ☆
特别的性能要求带来的考虑 ☆☆☆☆
特别的可恢复性要求带来的考虑 ☆☆☆
特别的信息安全要求带来的考虑 ☆☆☆

说明：
至于操作系统，数据库， 运行时环境等等可能不是由架构师决定，但如果没有其他人决定，或者领导要求一个初步方案时，架构师必须拿出意见。
就算别人已经决定了操作系统、数据库、 运行时环境等等，那么这些是下一步工作的前提和约束，也值得在架构设计文档中记述。

性能和安全的要求不是架构师定的，但如何保证实现性能和安全的要求，这是架构师必须考虑的问题。如果没有特别的要求，可以不考虑。
电信公司的应用和20人小公司的应用就算功能完全一样，初始设计就已经不一样了。
如果有特别的要求，比如交易所要每秒交易8万笔，对于干系人来说，这是最关心的，最核心的。

从数据库管理人员的角度来说， 数据库的设计说明是必不可少的，企业开发要特别关注于数据库 --- 对数据库管理人员来说，没错。但对于架构师在初期恐怕还不是一定必需的，可以给3颗星。