- 参考资料《解决方案架构师修炼手册》
解决方案架构文档(SAD) 是一个活文档，它在初始阶段被创建，并根据整个应用程序生命周期中的各种变化保持更新。
解决方案架构文档(SAD) 提供一种端到端的应用程序视图，目的是让所有的利益相关者达成一致，并就解决方案的设计和需求达成正式协议。由于利益相关者包括业务用户和技术用户，这就要求解决方案架构师必须了解SAD的各种视图。对于非技术用户，应包括业务、流程和逻辑视图等。对于技术用户，包括应用程序、开发、部署和运维视图等。
1.解决方案概述 #
在解决方案概述部分，需要用几段话简要介绍解决方案，粗略地描述解决方案的功能及其不同的组件。最好通过一个高级框图，将各种组件集中展示出来。
同时应当用直白的语言对每个组件进行简要介绍，以便业务用户能够了解解决方案的整体工作情况。
1.1 解决方案的目的 #
提供解决方案所要解决的业务问题的简要介绍，以及建立特定解决方案的理由。
1.2 解决方案的范围 #
对提出的解决方案所要解决的业务范围进行说明。明确描述解决方案无需处理的范围外内容。
1.2.1 在范围内的 #
1.2.2 超出范围的 #
1.3 解决方案的假设 #
列出所有解决方案架构师提出解决方案所基于的假设，例如最小网络带宽可用性。
1.4 解决方案的限制 #
列出所有的技术、业务和资源限制。通常情况下，制约因素来自行业和政府的合规条例，这些都需要在此列出。此外，还可以强调风险和缓解计划。
1.5 解决方案的依赖关系 #
列出所有上游和下游的依赖关系。例如，电子商务网站需要与UPS或FedEx之类的运输系统进行通信，以便将包裹运输给客户。
1.6 关键架构决策 #
列出主要问题的说明和相应的解决方案建议。描述每个方案的优缺点，做出特定决策的原因。
2.业务上下文 #
在业务上下文部分，解决方案架构师需要提供关于解决方案所支撑的业务功能和要满足的业务需求的概述。本节仅包含需求的抽象视图。详细的需求应当包含在单独的需求文档中。但是，这里可以提供需求文档的链接。
2.1 业务功能 #
提供解决方案所设计的业务功能的简要描述。确保其中描述了功能的优势，以及它们将如何满足客户需求。
2.2 关键业务需求 #
列出解决方案要解决的所有关键业务问题。提供关键需求的高层视图，并添加详细需求文档的链接。
2.2.1 关键业务流程 #
解决方案架构师应该使用业务流程文档来说明关键流程。(流程图)
2.2.2 业务利益相关者 #
列出受项目直接或间接影响的利益相关者，包括赞助商、开发人员、终端用户、供应商、合作伙伴等。
2.3 非功能性需求 #
解决方案架构师需要更多地关注非功能性需求，因为它们往往会被业务用户和开发团队忽略。
2.3.1 可伸缩性 #
随着工作负载的波动，应用程序如何伸缩？
例如，在某天或某月，从每秒1000次处理扩展到每秒10000次处理。
2.3.2 可用性和可靠性 #
从系统可用性出发，可以接受多长的停机时间。
例如99.99%的可用性或者每月允许45分钟的停机时间。
2.3.3 性能 #
系统的性能要求是什么？在不影响终端用户体验的前提下，系统可以承受多大的负载？ 例如，目录页需要在3秒内加载。
2.3.4 可移植性 #
应用程序能否在多个平台上运行而不需要任何额外处理？
例如，移动应用需要在iOS和Android操作系统中运行。
2.3.5 容量 #
应用程序能处理的最大工作负载是多少？
例如，最大用户数、请求数、预期响应时间和预期的应用程序负载等。
3.概念解决方案概述 #
架构的概念视图是一个可以为业务和技术利益相关者提供良好系统概览的最佳选择。
概念解决方案概述部分提供了一个抽象图，可以捕捉到整个解决方案的全貌，其中包括业务和技术两个方面。它为分析和比较研究提供了基础，有助于详细地完善和优化解决方案架构，以支持解决方案的设计和实施。
3.1 概念与逻辑架构 #
[TOOD: 找一个示例，可以展示重要模块及它们之间的信息流的抽象视图]
概念架构可以让业务和技术用户更好地理解整体架构。
4.解决方案架构 #
解决方案架构部分将深入介绍架构的每一个部分，并且提供不同的视图，技术 团队可以使用这些视图来创建详细设计并实施。具体的设计和表示方法，如4+1视图。
这些视图针对不同用户群，如开发人员、基础设施工程是、DevOps工程师、安全工程师、用户体验(User Experience，UX)设计师等。
4.1 信息架构 #
本节面向用户和用户体验(UX)设计师。
信息架构提供应用程序的用户导航流程。
解决方案架构师需要放入一个应用程序导航结构。
解决方案架构师可以添加更多的信息，如网站导航、分类或概括的线框图(UX设计师可以用它来生成详细的线框图)。
4.1.1 信息组件 #
4.2 应用程序架构 #
本节面向开发团队。
应用程序架构提供更多的实施细节，软件架构师或开发团队可以在此基础上构建详细的设计方案。
[TODO：添加案例]
4.2.1 应用程序组件 #
4.3 数据架构 #
本节面向数据库管理员和开发团队。 数据架构主要要定义数据库模式和表之间如何相互关联。通常情况下，需要包括ER图。
数据架构小节需要列出应用程序开发过程中需要考虑的所有数据对象。
4.3.1 数据流与上下文 #
4.4 集成架构 #
本节主要针对供应商、合作伙伴和其他团队。
也可以定义为「开放架构」。
集成架构主要需要列出与应用程序相关的所有上下游系统，以及它们之间的依赖关系。
4.4.1 接口组件 #
4.5 基础设施架构 #
本节主要针对基础设施团队和系统工程师。
基础设施架构需要包含部署图，需要定义服务器的逻辑位置及其依赖关系。
也可以针对不同环境定义部署图，如针对开发、质量保证(QA)和用户验收测试(UAT)环境独立生成图。
4.5.1 基础设施组件 #
4.6 安全架构 #
安全架构要包含应用程序的所有安全性与合规性内容，包括：
- 身份和访问管理(IAM)，如活动目录(AD)、用户认证和授权管理等。
- 基础设施安全，如防火墙配置、所需的入侵防御系统(IPS)/入侵检测系统(IDS)、防病毒软件等。
- 应用程序安全，如WAF、分布式拒绝服务(DDoS)保护等。
- 数据安全，在静止和传输中使用安全套接层(SSL)协议、加密算法、密钥管理等。
- 应用程序安全模型，以识别任何潜在的漏洞，如跨站脚本(XSS)、SQL注入(SQLi)等，并规划如何保护应用程序受任何安全威胁。
4.6.1 身份和访问管理 #
4.6.2 应用程序威胁模型 #
5.解决方案实施 #
解决方案实施部分包括开发和部署解决方案的基本注意事项。
5.1 开发 #
本节主要面向开发团队。
讨论开发工具、编程语言、代码存储库、代码版本控制和分支策略，及其选择依据。
这里不包含应用程序级的详细设计，例如类图或伪代码，因为这些细节需要由软件架构师或高级开发人员记录在相应的软件应用程序设计文档中。
5.2 部署 #
本节主要面向DevOps工程师
讲述部署方式、部署工具、各种部署组件、部署清单，及其选择依据。
5.3 数据迁移 #
本节帮助团队了解数据迁移和摄取方式、数据迁移范围、数据对象、数据提取工具、数据来源和数据格式等。
5.4 应用程序停用 #
本节列出需要停用的现有系统，以及在投资回报率(ROI)没有实现时，现有系统的退出策略。
解决方案架构师需要提供旧系统停用的方法和时间表，并进行整体影响评估。
6.应用程序管理 #
6.1 运维管理 #
本节主要面向运维管理团队。
应用程序管理专注于生产环境支持和跨其他非生产环境的持续的系统维护。
运维管理包括，如系统补丁和开发环境、测试环境、预置环境和生产环境的升级。
6.1.1 监控与告警 #
6.1.2 支持与事件管理 #
6.1.3 灾难恢复 #
6.2 用户入门 #
6.2.1 用户系统需求 #
7.附录 #
在解决方案设计过程中，解决方案架构师需要进行研究并收集数据来验证解决方案等正确性。相关附加细节可以放在附录部分。
附录部分是开放的，可以放入支持整体架构和解决方案选择的任何数据。
解决方案架构师也可以将未解决的问题、研究数据(如POC结果、工具对比数据、供应商和合作伙伴的数据等)放入附录部分。