文档介绍：系统架构说明书模板
秘密
[XXXX项目]
系统架构说明书
[说明:
1. 本文件中“[]”中内容为举例和说明文字，请在文件拟制时替换或删除; 2. 若文中某章节内容可省略、不需要或适用，请保留该标题，并根据实际在内容驱动。依次分析逻辑层tier和技术层layer，如下图的图示:
秘密
图1 架构框架
系统描述是通过一组架构视图来组织的，每一个视图都是从不同观点描绘系统特征的一个方面。系统层由大量的视图组织起来。
以每个或组服务级别需求作为一个次标题，加入架构设计中如何达到其需求的描述，需要的话引用其它视图;最后用一个总的服务级别需求视图把这些内容串联起来。
视图对读者是很有帮助的。不同的读者在特定的时间可能只对部分的视图感兴趣。 以下章节描述架构建立目标和约束，以及高层次系统整体概要。本节也描述后续章节从不同侧面检验系统架构的上下文环境。
架构约束
[本节需描述四方面的内容。1)本系统最受关注的前几个服务级别需求对架构的要求。(详细的服务级别需求可以在服务级别需求部分表述)2)是否是基于外购系统。(全部基于或部分基于外购系统或全部自主研发)3)本系统的架构适用范围。(只适用本系统还是可以适用于其余系统或者部分可适用于其余系统。如果是部分可适用于其余系统，则需要描述架构模式) 4)本系统的技术约束(需依赖的技术)，对团队成员的约束(如成员需要掌握的技能)，软硬件约束等。]
整体概要
[提供一个架构的整体性说明。因为在后续的章节中，都是按层(layer)来组织该层(layer)的视图，本概述章节就更适合把所有层(layer)作为一个整体来考虑，而不是分层(layer)来描述。通常，划分层(tier)是很有用的，突出(加亮)每级的关键点，这些关键点包括主要的外部实体(如终止用户访问的节点和遗留系统)。主要的架构特征列表，如:独立供应商、一致的行业标准、产物的构思等。同一类架构特征应该放进整体说明中描述。]
秘密 系统上下文
[描述本系统与参与者(内部、外部)的关联关系]
整体架构
[描述系统整体架构]
3. 应用层
[本节在均衡考虑架构统一原则的基础上,通过分解对应用层的功能进行讨论。从概要地描述应用层
各独立视图开始，例如:分别对比静态和动态的结构视图，分别对比静态和动态的配置视图。] 设计思路
[整体描述应用层整体的设计思路,例如使用Pafa3架构作为基础框架代码;cache缓存在app
Server及其原因等.]
结构视图
[当需要进行开发时，描述架构上重要的包和它们之间编译时的静态依赖关系。选择的分解应该详
细阐述每条定义明确的分解规则，例如:分层、分类、概括等。一旦包括各等级的小节，就可以用
一个等级分层的概要图表作为开始，然后用更加详细的图表描述架构上比较重要的部分。所有的图
表中对每个包的描述，应该包括它们的职责和资源(自定义的、可重用的、成本等)的描述。]
[本小节可以放到本节开头部分，但是要先于各小节提出。无论是放在此处还是其他地方，推荐保
留次级标题，即使内容是空的，也要作为详尽阐述的占位符。]
包视图
XX包的描述
[描述xx模块的职责/功能范围]
类图
包内接口或服务
[声明用例中系统执行操作对应的服务，为其他模块提供的服务]
YY包的描述
[描述YY模块的职责/功能范围]
类图
包内接口或服务
[声明用例中系统执行操作对应的服务，为其他模块提供的服务]
外部服务
[描述调用的外部接口或对外提供的外部接口]
使用关联系统的服务
[描述使用关联系统的服务]
秘密 为关联系统提供的服务
[描述为关联提供提供的服务,可以参见接口文档的服务]
配置视图
[逐条描述各应用模块的配置，包括这些模块的物理位置、运行时的交互。为此，可以使用模块结构图覆盖展开图。为不同的配置提供适合的多样的图表，可能需要产品的例子、或配置于不同环境中的产品的例子、决定支持配置与交易配置不同之处的例子。当描述各种配置时，应当定义为每项配置所选的配置策略。]
[注明底层的详细信息将在稍后的独立配置视图中获取，所以最好在此赘述一下相关的视图信息。]
配置视图
配置描述
[如果有需要，可以在视