解决方案架构从战略和战术的视角，对业务解决方案的方方面面进行定义和展望。 解决方案架构不仅仅是软件解决方案，它涵盖了系统的方方面面，包括但不限于系统基础设施、网络、安全、合规性要求、系统运维、成本和可靠性。
解决方案架构是整体企业软件解决方案的基础构件，用于解决特定的问题和需求。 解决方案架构可以解决各种解决方案需求，保持业务上下文的完整性。它指定并记录了技术平台、应用程序组件、数据需求、资源需求以及许多重要的非功能性需求，如可伸缩性、可靠性、性能、可用性、安全性和可维护性。 解决方案架构有助于让所有领域的利益相关者达成共识(从非技术性的业务功能到技术开发)，从而避免混乱，确保项目的进度和时间不脱离正轨，并有助于获得最大的投资回报率(Return On Investment, ROI)
一个问题可以有多种解决方案，每个解决方案都有其约束。 解决方案架构考虑所有的解决方案，并通过创建能够适应所有业务和技术限制的概念验证，并寻求最佳方案。
解决方案涉及的视图 #
视图是为了让所有业务人员和技术利益相关者容易阅读和理解。
业务视图 #
架构设计是为了解决业务问题，明确业务目的。业务视图显示了整体解决方案和产品的价值主张。为了简化起见，解决方案架构师可以选择识别出与业务相关的高级场景，并将其以用例图的形式展现出来。业务视图海描述了利益相关者和执行项目所需的资源。业务视图也可以定义为用例图。
[TODO:业务视图的例子]
逻辑视图 #
逻辑视图展示了系统上的各种程序包，以便业务用户和设计人员可以明了系统的各种逻辑组件。逻辑视图提供了它所应当构建的系统的时间顺序。它显示了系统的多个组件是如何连接的，以及用户如何与它们交互。
[TODO：逻辑视图的例子]
流程视图 #
流程视图呈现更多的细节，显示系统的关键流程如何协作工作。这一切也可以用状态图来反映。如果想要展示更多的细节，还可以创建序列图。
[TODO：流程视图的例子]
部署视图 #
部署视图展示了应用程序如何在生产环境中工作，以及系统的不同组件(例如网络防火墙、负载均衡器、应用服务器、数据库等)是如何连接的。解决方案架构师应当创建简单的框图，便于业务用户理解，还可以在UML部署图中添加更多细节，向技术用户(如开发团队和DevOps团队)展示各种节点组件及其依赖关系。部署视图可以展示系统的物理布局。
[TODO：部署视图的例子]
实现视图 #
解决方案架构文档(SAD)的核心，体现了架构上和技术上的选择。解决方案架构师需要把架构图设置在这里，例如，显示它是3层、N层架构，还是事件驱动的架构，以及其背后的理由。还需要详细说明技术选择，例如，Java与Node.js的使用对比，以及它们各自的利弊。需要在实现视图中说明执行项目所需的资源和技能。开发团队使用实现视图来创建详细的设计(例如，类图)，但这不需要作为SAD的一部分。
[TODO：实现视图的例子]
数据视图 #
由于大多数应用程序都是数据驱动的，因此数据视图尤为重要。数据视图显示了数据如何在不同组件之间流动，以及如何存储。它还可以用来解释数据安全性和数据完整性。解决方案架构师可以使用实体关系(Entity-Relationship, ER)图来显示数据库中不同表与模式之间的关系。数据视图还可以对所需的报告和分析进行说明。
[TODO：数据视图的例子]
运维视图 #
运维视图解释了系统在启动后如何进行维护。通常情况下，需要定义SLA、告警和运维监控功能、灾难恢复计划，以及系统的支持计划。运维视图还提供了有关如何进行系统维护的详细信息，包括修复Bug、打补丁、备份和恢复、处理安全事件等。
[TODO：运维视图的例子]
其他视图 #
还可以根据利益相关者的要求来提供额外的视图，如：
- 物理视图
- 网络架构视图
- 安全(控制)架构视图
- …
解决方案架构文档模版 #
参考资料 #
- 《解决方案架构师修炼手册》