Architecture 作为整体软件设计的一部分，你认为什么样的体系结构观点？

当有人使用XXX架构这个术语时，我往往会畏缩。它经常表明，我可能没有考虑到另一个架构规程或视角。你在考虑架构的哪些方面？你有什么好的资源来提供这些方面的信息吗

我希望这能帮助其他在建筑行业工作的人

• 生存能力
• 绩效管理
• 运营监控与管理
• 服务导向
• TOGAF定义了许多服务质量属性

很抱歉编辑了，但是你的答案很准确，我认为这个问题需要改进

• 可测试性
• 可伸缩性
• 容错性
• 性能下降（人们希望是优雅的）
• 可升级性（硬件和软件）

---

顺便说一句，这些都是我喜欢企业服务总线（ESB）的原因

编辑：由于问题的重点发生了变化，我将我的答案编辑如下

架构和架构师是重载的术语。首先，您需要指定您谈论的是软件公司（软件是产品/服务）还是业务线公司（软件支持产品/服务）

还有自上而下的架构视图（从组织的角度来看，什么是重要的）和自下而上的视图（从项目需求的角度来看，什么是重要的）

在大型业务线公司中，从自上而下（组织）的角度来看，架构通常是这样划分的：

• 架构，有时称为业务架构。例如，了解商品交易流程和相关IT系统
• 建筑。例如，理解存储中数据和运动中数据的描述；数据存储、数据组和数据项的说明；以及这些数据工件到数据质量、应用程序和位置的映射
• 建筑。例如，了解企业、解决方案或系统的技术基础架构的结构和行为

从自下而上（需求）的角度来看，我的体系结构区域如下所示：

• 正确使用中间件-松耦合、容错、特定于目标的转换、消除点对点等
• 识别并设计出尽可能多的对账
• 识别并设计出尽可能多的双钥匙
• 识别并设计出尽可能多的手动流程
• 确定并设计任何最终用户计算解决方案-例如Access数据库、Excel电子表格
• 识别并设计出任何最终用户对“答案”的编辑——在所有工作完成后获取信息，然后对其进行编辑
• 调查完整的数据生命周期：谁拥有它，谁丰富它，谁分发它，真相的单一版本，消除矛盾
• 确定性能和可伸缩性指标，根据多个数据配置文件测试风险区域
• 识别实时与批处理流程和接口，并在可行的情况下消除批处理依赖关系
• 在可能的情况下整合到单个平台，以及单个实例与多个实例的对比
• 能够在合理的时间范围内快速处理新的普通业务和新的复杂业务
• 确定明确的支持模式，特别是必要时跨区域的支持模式
• 状态维护和恢复—每天处理和接口故障的恢复情况
• BCP/DR要求和能力、一般容错、广域网依赖性
• 在哪里可以降低项目风险
• 安全、最终用户和开发人员访问、生产周围的钢环
• 有哪些MI报告设施
• 尽可能强调简单性，系统停止调试

  ---

体系结构和体系结构决策主要是关于系统的“非功能性”需求；但他提到的每一件事都是架构决策的结果，而不仅仅是独立的。（证据：是什么导致这些领域中的某个特定选择？总是需要满足一些非功能性需求。）

考虑到这一点，这是一个由两部分组成的问题。首先，您需要确定哪些NFR是重要的。最好通过使用严格的方法以某种特定性来说明它们，例如，不要只说“高度可用”，说“系统必须可用（MTTF/（MTTF+MTTR））99.99%，最长的单次持续停机时间为4分钟。”

第二，你需要考虑哪些观点会帮助你设计满足这些要求并为你的决定辩护。根据需求的严格程度，这可能是从白板框图到正式模拟研究的任何内容

在业务领域中，例如在通过web界面提供的IT系统中，您可能需要：

• 可靠性（MMTF）
• 可用性（MTTF/（MTTF+MTTR））
• 可扩展性（系统必须能够在72小时内以X成本增加10%的容量）
• 容量（系统必须支持100万活跃用户）
• 吞吐量（系统必须每秒处理100个事务，平均σ=2.5 tps）
• 响应时间（在测试负载下），用户必须在≤ （2秒）
• 安全性（这里的指标本身就是一篇文章的主题）

如果要指定性能等特征，还应该描述工作负载，即用户数据的大小、web请求的到达率